[AWS] flAWS Challenge - Level5

flAWS

 

 

문제확인

=> 해당 문제에서는 그저 HTTP proxy 역할만하는 EC2를 sample로 주고 사용법을 알려주고 있다. 실제로 proxy인지 테스트 해보았고 진짜 단순한 proxy였다(http를 사용하는 페이지인 me.go.kr로 시도해도 바로 Redirect 되어버리지면 역시나 proxy처럼 동작했다)

 

 

=> 뭔가 해결을 한뒤 http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/에 접근할 수 있어야하는데 접속해보니 Access Denied가 났고 내용을 보니 sub-directory를 알아야하거나 Credential 정보를 알아야 접근할 수 있을 것 같다.

 

 

 

Instance Metadata 검색

인스턴스 메타데이터 검색 - Amazon Elastic Compute Cloud

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/

=> Instance metadata를 통해서 정보를 구해보자. AWS instance metadata는 IP 169.254.169.254를 사용한다. Amazon에서 제공하는 공식 문서를 보고 경로를 추가해서 접근해보았다.

 

 

 

=> 문제에서 제시한 proxy를 통해 AWS metadata들에 접근할 수 있었고 해당 파일중에는 iam이나 identity-credential에 뭔가 필요한 내용이 있을 것만 같았다.

 

 

 

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/

 

 

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/

 

필요 Credential 확인

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

=> 쭉 따라서 확인해보니 flaws에 대한 Credential을 얻을 수 있었다. Access key, SecretAccess key 뿐아니라 Token도 확인된 것으로 볼때 token까지 사용해야하는 것으로 보여진다.

 

 

 

aws cli credential 추가

https://docs.aws.amazon.com/ko_kr/sdkref/latest/guide/file-format.html#file-format-creds

공유 config 및 credentials 파일 - AWSSDK 및 도구

.aws/credential

=> aws credential 파일 내에 access key, secret access key, token 값을 복붙해주었다. profile은 test로 설정해주었다. 그렇다면 이제 해당 credential profile로 level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/에 접근이 가능한지 시도해보자.

 

 

 

해당 Credential을 이용하여 S3 bucket 객체 Listing

aws s3 ls --profile test s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/

=> 해당 경로의 s3를 Listing 하였더니 index.html과 ddcc78ff라는 디렉터리가 확인되었다. index.html은 우리가 아까보았던 Access Denied일 것이므로 ddcc78ff에 접근해보았따.

 

 

 

http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/

=> 다음 Level로 갈 수 있게 되었다. 169.254.169.254 IP를 활용하여 Instance의 metadata를 받아오는 것을 시작으로 문제를 풀 수 있었다. 따라서 해당 metadata에 대한 요청은 되도록이면 클라우드 내부에서만 요청가능하도록 설정해야하며 metadata 서비스를 호출할 수 있는 애플리케이션 또는 프로세스를 필요에 따라 제한하는 등의 관리가 필요할 것으로 보여진다.