[Bugbounty Study] #Amazon S3 _ Sensitive Data Exposure

# Sensitive Data Exposure _ $400

virdoexhunter.medium.com/misconfigured-s3-bucket-leads-to-sensitive-data-exposure-no-super-controls-f47e26b586c6

Misconfigured s3 bucket leads to Sensitive Data exposure(No super controls )

해당 글은 잘못된 S3 버킷을 통해 이전 서버 코드와 인증 파일(users.htpasswd)이 노출된 사례에 대한 글이다.

 

Amazon S3 (Simple Storage Service) 란?
널리 쓰이는 인터넷용 스토리지 서비스이다.
많은 기업이 S3 버킷을 사용하여 사용자 프로필 사진, 정적 리소스, 비즈니스 로직과 니즈 등의 자신들의 자산을 저장하고 있다. 따라서, 버킷이 올바르게 구성되지 않은 경우에 공격자는 S3 버킷 탈취 또는 콘텐츠 탈취 등을 수행할 수 있다.

[참고] https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/Welcome.html

 

우선 아래의 명령어를 이용하여 모든 살아있는 서브도메인을 알아냈다.

 

$ Subfinder -d target.com | httpx | tee -a alive.txt

[참고]
- https://www.cyberpunk.rs/subfinder-subdomain-discovery-tool
- https://www.python-httpx.org/
- https://twpower.github.io/135-tee-command-usage

 

살아있는 도메인(site.com) 뒤에 /%C0를 추가하여 요청하였다.

 

https://site.com/%C0

 

그 결과, 아래와 같이 cloudflare error 페이지를 얻었다.

 

<Error>
<Code>InvalidURI</Code>
<Message>Couldn’t parse the specified URI.</Message>
<URI>/%C0</URI>

 

타겟 도메인에 .s3.amazonaws.com을 추가하여 요청하였더니 버킷의 이름을 얻을 수 있었다.

 

https://target.com.s3.amazonaws.com/

 

dig 명령어를 이용해 해당 버킷에 대한 CNAME을 알아냈다.

 

$ dig site.com

[참고]
- https://carpfish.tistory.com/entry/DNS-dig-명령어-소개-및-사용법
- https://hippogrammer.tistory.com/142

 

이것들을 통해 무엇을 할 수 있을지를 생각하다가 잘못 구성된 S3으로 발생한 취약점에 대한 글을 읽게 되었다.

 

---

원작자가 읽은 글의 내용을 간단히 요약하면 다음과 같다.

 

1. subfinder 명령어를 이용하여 서브도메인(https://qa-assets-us.subtarget.com)을 발견함.
2. 해당 서브도메인을 탐색하는 동안 버킷이 열려있고, 버킷 결과 목록이 표시됨.
3. S3 버킷 이름을 제공하는 항목을 확인함.
   <Name>some-name-here</Name>
4. S3 버킷의 액세스 제어 테스트(AWS CLI, 기본 명령어 이용).
   (일반적으로 버킷은 허가되지 않은 사용자에게 CRUD 권한을 제공하지 않아야 함.)
5. 명령어를 이용하여 S3 버킷에 업로드가 가능한 지 확인.
   $ aws s3 cp yourtestfile.txt s3://bucketname
6. 성공하면, 다음과 같은 것을 확인할 수 있음.
   upload: ./yourtestfile.txt to s3://bucketname/yourtestfile.txt
7. 파일 삭제 테스트(영향력 증가시키기 위함).
   $ aws s3 rm s3://bucketname/yourtestfile.txt
8. 파일 업로드와 삭제가 가능하면, 기존의 리소스 파일을 삭제시킨 후 같은 이름의 파일을 업로드하여 해당 리소스를 참조하는 모든 애플리케이션에 공격자가 정의한 리소스가 표시되게 할 수 있기에 영향력이 증가한다.

[취약점 요약]
1. S3 열린 버킷 확인 및 버킷 이름 찾기.
2. AWS CLI를 이용하여 S3 버킷 액세스 제어 확인하기.
3. 모든 C.R.U.D 작업을 확인하여 영향력 증가시키기.

 

[참고]

medium.com/bugbountywriteup/s3-bucket-misconfigured-access-controls-to-critical-vulnerability-6b535e3df9a5

S3 Bucket Misconfigured Access Controls to Critical Vulnerability

---

본문으로 돌아와서,

원작자가 테스트해 본 결과 CRUD(생성, 읽기, 갱신, 삭제)는 접근이 거부되어 불가능하였다.

그래서 아래 명령어를 이용하여 확인해보았다.

 

$ aws s3 ls s3://target-bucketname

 

그 결과, 응답에서 PRE Server/를 얻었고, 이를 확인하여 server.js 와 users.httpasswd 파일을 발견하였다.

이는 이전 서버 코드와 인증 파일에 접근하여 읽을 수 있는 결과이다.