[1주차] S3 취약점 및 보안

🚨 해당 포스트는 CloudNet@의 서종호 (Gasida) 님께서 진행하시는 AHSS (AWS Hacking & Security Study) 1기의 강의 내용을 바탕으로 작성되었습니다.

 

첫 주차에는 S3에서 일어날 수 있는 취약점과 보안 사항에 대해 다룬다.

먼저, S3라는 서비스에 대해 낯설게 느껴지는 사람도 있을 터이니 이에 대해 간략하게 짚고 넘어가고자 한다.

AWS에서는 블록 스토리지, 파일 스토리지, 오브젝트 스토리지의 세 가지 종류로 스토리지 서비스를 제공하고 있는데, 각각 EBS, EFS, S3에 대응된다. 

 

1. AWS S3란 무엇인가?

AWS S3는 Simple Storage Service의 두문어로서, AWS에서 제공하는 무제한 오브젝트 스토리지 개념으로 이해하면 쉽다. 일반적으로 많이들 사용하는 블록 스토리지의 경우에는 데이터를 블록 단위로 관리하기 때문에, 데이터의 일부에 수정사항에 생길 경우, 변경사항이 발생한 블록에 대해서만 업데이트 작업을 수행해주면 된다. 하지만, S3의 경우 데이터를 오브젝트 단위로 관리하기 때문에 오브젝트에서 수정사항이 발생할 경우, 오브젝트 전체를 flush하고 새로 작성하게 된다. 파일의 크기가 큰 데 반해, 수정사항의 크기는 작을 경우 비효율적일 수 있지만, 속도가 빠르고 스토리지 용량을 고려하지 않아도 되기 때문에 작은 크기를 가지면서 변경이 잦은 동적인 파일을 관맇려는 경우에는 S3를 이용하는 것이 유용할 수 있겠다. 그림과 함께 다시 이해가 필요한 사람은 여기를 통해 확인해보도록 하자. (그림 추가 예정)

 

 

 

2. AWS S3 세팅해보기

S3를 사용하기 위해 우선 AWS CLI 환경 구성과 키 페어를 발급하도록 하자. 특히 키 페어는 재발급이 불가능하므로 분실하지 않도록 안전한 곳에 잘 보관하도록 하자. 

yaml 형식으로 사전 정의되어있는 템플릿을 사용하여 빌드할 예정이다.

Storage.yaml

0.01MB

사진 상에서는 링크를 사용하였지만, 따라하시는 분들은 첨부파일을 업로드해서 사용하시면 됩니다.

 

우리는 별도의 경로로 준비된 템플릿을 사용하여 스택을 빌드할 것이기 때문에 '준비된 템플릿'을 선택한 다음, 위에첨부된 파일을 업로드하면 된다.

 

스택의 이름은 임의로 지정하면 되며, 파라미터 란의 키는 이전에 미리 생성해둔 EC2 키페어를 사용하면 된다.

이후의 작업은 EC2 인스턴스에서 수행할 것인데, 우리는 AWS에서 제공하는 웹 쉘(?)인 AWS CloudShell을 사용할 것이다. 해당 서비스를 이용하면 SSH나 VNC 등의 프로토콜을 이용하지 않아도 웹 브라우저 상에서 바로 콘솔에 접근할 수 있다.

 

클라우드 쉘을 통해 S3 버킷 을 생성해 주도록 하자. 

# S3 버킷 생성
NICKNAME=<자신의 닉네임>
aws s3 mb s3://ahss-NICKNAME --region ap-northeast-2

# 생성한 S3 버킷 조회
aws s3 ls

버킷 생성에 실패한 경우

아직 템플릿을 빌드중인 경우 버킷이 생성되지 않는다. 이러한 경우에는 조금 더 기다리고 다시 진행해보도록 하자.

 

버킷 생성에 성공한 경우

 

 

 

3. S3에 오브젝트 추가하기

  S3 버킷을 성공적으로 만들었으니 이제 버킷에 오브젝트를 추가해보자. 이번에는 간단한 텍스트 파일 3개를 업로드해보자. 아래의 코드를 따라해보자.

# 파일 생성
echo "memo1" > memo1.txt
echo "memo2" > memo2.txt
echo "memo3" > memo3.txt

# S3로 업로드
aws s3 cp memo1.txt s3://ahss-$NICKNAME
aws s3 cp memo2.txt s3://ahss-$NICKNAME
aws s3 cp memo3.txt s3://ahss-$NICKNAME

# 파일 확인
aws s3 ls s3://ahss-$NICKNAME --recursive --human-readable --summarize
aws s3api list-objects --bucket ahss-$NICKNAME | jq​

파일이 정상적으로 생성되고 업로드되었다면 아래의 캡처와 같이 ls 명령어를 통해 정상적으로 버킷에 파일이 담겼는지 확인할 수 있다.

aws s3 ls s3://ahss- $NICKNAME --recursive --human-readable --summarize

또한, 업로드된 파일은 코드블럭의 가장 하단에 기재된 list-object 명령어를 통해 자세한 세부정보도 파악할 수 있으니 참고하자.

 

이렇게 CLI 환경을 통해 파일을 업로드한 내용은 AWS 웹 콘솔 상에서도 실시간으로 반영되기 때문에 AWS 웹 콘솔에 접속할 경우 아래와 같은 화면을 확인할 수 있다. 

 

 

 

 

4. AWS S3의 보안 정책 알아보기

AWS S3에는 크게 4가지의 보안 정책을 적용할 수 있습니다. 이번 장에서는 이에 대해 살펴봅니다.

AWS S3에 적용할 수 있는 보안 정책의 4 종류

1. 객체/버킷 ACL (Access Control List)

  가장 먼저 객체 ACL입니다. 객체 ACL의 사용은 AWS 측에서도 공식적으로 비권장하고 있는데, 그 이유는 객체별로 ACL을 관리할 경우 제대로 관리가 이루어지지 않는 케이스가 매우 많기 때문으로, 반드시 각 객체에 대한 접근 권한을 개별적으로 제어해야만 하는 경우가 아니라면 버킷 정책을 통해 다른 사용자의 접근 권한을 관리하도록 오브젝트를 공유하도록 권장하고 있습니다. 객체 ACL의 설정 변경은 'S3 > 버킷 > [버킷 명] > 권한 (탭) > 객체 소유권 (블록) > 편집' 을 통해 접근 가능합니다. S3 버킷을 처음 생성하고 나면 기본적으로 퍼블릭 접근 권한이 모두 차단되어 생성됩니다.

ACL을 활성화하면, 아래와 같이 ACL 권한을 편집할 수 있는 화면에 접근할 수 있게 된다. 퍼블릭 액세스에서 객체를 확인할 수 있도록 설정을 변경해보자. 

여기까지 잘 따라왔다면 콘솔에 아래의 명령어를 입력해서 퍼블릭 액세스 권한에서 파일 목록일 잘 읽어올 수 있는지 확인해볼 수 있다.

# 탐색 실행
aws s3 ls s3://ahss-$NICKNAME --human-readable --no-sign-request

# Memo1.txt 파일을 복사
aws s3 cp s3://ahss-$NICKNAME/memo1.txt . --no-sign-request

  --no-sign-request 옵션을 주었기 때문에 버킷 소유자 권한 없이 접근을 시도하고 있는데, 우리는 방금 퍼블릭 액세스에서도 파일을 나열할 수 있는 권한을 부여했기 때문에 ls 명령어를 사용할 수 있지만, 파일을 복사하려고 시도하는 경우 파일에 대한 읽기 권한은 부여받지 않았기 때문에 permission denied (Forbidden) 라고 표출되는 것을 확인할 수 있다.

 

 

 

2. 버킷 정책

  다음으로는 버킷 정책에 대해서 살펴봅니다. 버킷 정책에서는 작업의 종류, 요청자, 접근하는 항목의 옵션 등 다양한 조건을 지정하여 객체/버킷에 대한 중앙 집중식 접근 제어 방식을 제공합니다. 클라우드플레어 DNS를 사용하고 계신 분들이라면 아래의 이미지처럼 Cloudflare Dashboard에서 Page Rules라는 기능을 통해 특정 URL로 접근시에 어떠한 보안정책을 적용할 것인지 개별적으로 설정할 수 있는 기능을 제공하고 있는 것을 알고 계실겁니다. AWS S3의 버킷 정책에서도 이와 유사하게 사전에 정의된 다양한 조건문을 걸어 특정 조건을 만족할 경우에만 객체/버킷에 접근할 수 있도록 설정할 수 있다고 생각하시면 됩니다. 

Cloudflare DNS에서 제공하는 Page Rules 기능

버킷 정책에서 적용되는 사항은 아래와 같습니다.

1. 버킷 정책에 적용되는 기본 설정은 모든 하위 오브젝트에도 동일하게 적용

2. ACL에서는 단일 객체에 대해서만 정책을 적용할 수 있지만, 버킷 정책에서는 버킷 전체에 대해 정책을 적용하거나, 특정 오브젝트와 그 하위 오브젝트에 대해 재귀적으로 정책을 적용할 수 있음

 

이제 실제로 적용해봅시다. 여기에서는 아래의 JSON 형식의 예제 코드를 복사하여 사용합니다.

( [[NICKNAME]] 자리에는 실제 인스턴스의 도메인을 적어주세요.)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ahss-[[NICKNAME]]/*"
        }
    ]
}

 

  버킷 정책을 적용했다면, 이번에도 클라우드 쉘을 통해 정상적으로 적용되었는지 확인해봅시다. 아래의 명령어를 입력하면 현재 적용되어있는 버킷 정책을 콘솔에 출력하도록 만들 수 있습니다.

aws s3api get-bucket-policy --bucket [[Name of Bucket]] | jq -r .Policy | jq

 

  해당 버킷 정책을 통해 퍼블릭 액세스 권한으로도 특정 오브젝트에 접근하여 GET 요청을 보낼 수 있도록 허용하였으므로, 역시 직접 테스트해보도록 합시다.

  퍼블릭 액세스의 경우에도 정상적으로 파일을 다운로드하는 것을 확인할 수 있습니다.

 

 

 

3. IAM (Identity and Access Management) 정책

  마지막으로 IAM 정책에 대해 다뤄봅니다. IAM 정책을 S3 버킷에도 동일하게 적용할 수 있는데, 여기에서는 실습용으로 firstanalyzer라는 이름의 액세스 분석기를 만들어 사용하도록 하겠습니다. 액세스 분석기는 AWS의 리소에 대해 꼭 필요한 최소한의 권한만 부여할 수 있도록 도와주는 역할을 수행합니다. 액세스 분석기에 대한 자세한 문서는 여기에서 확인할 수 있습니다.

  액세스 분석기는 웹 콘솔을 통해서도 생성하고 관리할 수 있지만, 여기에서는 클라우드 쉘을 통한 CLI 환경에서 액세스 분석기를 생성해보겠습니다. 아래와 같이 명령어를 입력하면 액세스 분석기를 생성할 수 있습니다. 이 작업을 수행하기 전에는 클라우드 쉘의 리전과 동일한 위치에 분석기가 생성되므로, 명령어를 입력하기 이전에 본인이 액세스 분석기를 생성하고자 하는 리전으로 이동한 다음에 작업을 수행해주세요.

# 액세스 분석기 생성
# 자격증명 필요
#aws accessanalyzer create-analyzer --analyzer-name firstanalyzer --type ACCOUNT --output text --query arn
ANA_ARN=$(aws accessanalyzer create-analyzer --analyzer-name firstanalyzer --type ACCOUNT --output text --query arn)
echo $ANA_ARN
==
arn:aws:access-analyzer:ap-northeast-2:276281595736:analyzer/firstanalyzer
==

AWS AMI Access Analyzer에서는 자동 스캐닝을 제공합니다. 다음 명령어를 통해 스캔을 수행하고 그 결과를 콘솔에 출력할 수 있습니다.

# S3 버킷 스캔 수행
# 기본적으로 자동으로 스캔 합니다.
aws accessanalyzer start-resource-scan --analyzer-arn $ANA_ARN --resource-arn arn:aws:s3:::ahss-$NICKNAME

# S3 버킷 스캔 결과 확인
aws accessanalyzer get-analyzed-resource --analyzer-arn $ANA_ARN --resource-arn arn:aws:s3:::ahss-$NICKNAME | jq

  저는 이전에 수행한 실습 이후 각각의 정책을 모두 비활성화하거나 제거한 상태이기에 저렇게 표시되는 것이며, 이전에 진행한 실습 사항을 그대로 유지하신 분들은 각자 현재 본인의 버킷에 적용된 정책이 반영되어 표시됩니다.

  만약에 퍼블릭 액세스가 가능하도록 설정되어 있는 상황에서 다음 명령어를 입력하면 어떻게 되는지 확인해봅시다.

aws s3api put-public-access-block --bucket ahss-$NICKNAME --public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

  위의 캡처 이미지에서 확인할 수 있는 것처럼 퍼블릭 액세스가 가능하도록 권한 설정이 되어 있는 상태에서 퍼블릭 액세스를 막는 'public-access-block' 명령을 수행한 결과 이와 관련된 모든 정책이 수정된 것을 확인할 수 있습니다.

 

 

 

5. 실습에 사용한 인스턴스 제거하기

  이제 모든 실습이 끝났습니다. 다음 명령어를 입력하여 지금까지 실습에 사용한 모든 인스턴스를 종료해주시고 웹 콘솔을 통해 다시 한 번 확인하시기 바랍니다. 여기까지 따라오시느라 고생하셨습니다.

# 액세스 분석기 제거
aws accessanalyzer delete-analyzer  --analyzer-name firstanalyzer

# 버킷에 객체 모두 삭제
aws s3 rm s3://ahss-$NICKNAME --recursive
# 실습에 사용한 S3 버킷 삭제
aws s3 rb s3://ahss-$NICKNAME
# 확인
aws s3 ls