▲

GN⁺: 어떤 S3 버킷의 AWS 계정 ID를 찾는 방법

 (tracebit.com)
2P by neo 7달전 | favorite | 댓글 1개

S3 버킷의 AWS 계정 ID 찾기

  • 2021년 Ben Bridts가 공개된 S3 버킷의 AWS 계정 ID를 찾는 독창적인 방법을 발표함.
  • 이 글에서는 비공개 및 공개 S3 버킷 모두의 계정 ID를 찾는 기술을 설명함.

S3 버킷에서 AWS 계정 ID로

  • 쉘 출력을 통해 bucket-alpha라는 버킷의 이전에 알려지지 않은 AWS 계정 ID를 찾는 기술을 보여줌.

이 기술은 정확히 어떻게 작동하는가?

  • Ben의 기술이 작동하는 이유를 분석하여 세 가지 핵심 요소를 결합함:
    • IAM 정책을 요청에 적용할 수 있는 능력
    • IAM 정책이 요청을 허용했는지 여부를 추론할 수 있는 능력
    • s3:ResourceAccount 조건 키에 와일드카드 매치를 적용할 수 있는 능력

해결책

  • S3용 VPC 엔드포인트를 사용하고 CloudTrail에서 요청이 거부될 때의 행동 차이를 이용하는 해결책을 찾음.

단계별로 살펴보기

  • 버킷 bucket-alpha의 계정 ID를 찾고자 할 때의 단계별 절차:
    • 버킷 지역 결정
    • 동일 지역에 VPC 및 VPC 엔드포인트 배포
    • VPC 내에서 EC2 인스턴스 시작 및 S3에 대한 VPC 엔드포인트 사용 확인
    • 대상 버킷의 계정 ID가 "0"으로 시작하는지 여부를 결정하기 위해 VPC 엔드포인트 정책 수정
    • 대상 버킷에 요청하기
    • CloudTrail에서 요청이 나타나는지 확인
    • 결과에 따라 VPC 엔드포인트 정책을 수정하여 계정 ID에 대한 정보를 더 발견

결과

  • 이 과정을 자동화하는 스크립트를 작성하여 버킷의 계정 ID를 신뢰할 수 있게 찾을 수 있음.
  • 각 숫자에 대해 이진 검색을 수행하여 필요한 테스트 수를 줄임.

속도 향상

  • VPC 엔드포인트 정책이 효과를 발휘하고 CloudTrail에서 결과를 개별적으로 기다리는 데 걸리는 시간을 줄이기 위해 VPC 엔드포인트 정책을 수정함.
  • 이를 통해 계정 ID를 찾는 데 걸리는 시간을 10분 미만으로 단축함.

의견

  • AWS 보안 팀과 상의한 후 이 블로그 게시물을 게시함.
  • AWS 계정 ID가 민감한 정보로 간주되어야 하는지에 대한 흥미로운 토론이 있었음.
  • 이 기술은 S3 외에 다른 서비스에도 적용될 수 있음.
  • 이러한 기술은 s3:ResourceAccount에 대해 StringLike 조건을 사용할 수 있기 때문에 가능함.
  • VPC 엔드포인트 정책에 의해 거부된 이벤트가 CloudTrail에 로깅되는 것이 유익할 수 있음.

감사의 말

  • Ben Bridt의 원래 기술이 이 작업에 영감을 줌.
  • Chris Farris의 도움과 조언에 대해 감사함.

GN⁺의 의견

  • 이 기술은 클라우드 환경에서 보안 감사를 수행하는 데 매우 유용할 수 있으며, 특히 AWS S3 버킷의 소유권을 확인하는 데 도움이 될 수 있음.
  • 이 기술이 제공하는 정보의 민감성에 대한 논의는 클라우드 서비스 제공자와 사용자 간의 데이터 보안과 프라이버시에 대한 지속적인 대화를 반영함.
  • 비슷한 기능을 제공하는 다른 도구로는 AWS의 자체 서비스인 CloudTrail이 있으며, 이는 사용자의 AWS 환경에서 발생하는 모든 활동을 로깅하고 모니터링하는 데 사용됨.
  • 이 기술을 도입하기 전에, 사용자는 해당 기술이 AWS의 정책 및 보안 모범 사례와 일치하는지 확인해야 함.
  • 이 기술을 사용함으로써 얻을 수 있는 이점은 효율적인 보안 감사와 빠른 데이터 소유권 확인이지만, 잠재적인 개인정보 노출과 같은 위험도 고려해야 함.
▲
neo 7달전  [-]
Hacker News 의견

  • AWS의 s3:ResourceAccount 조건 키에 와일드카드 매치를 적용할 수 있는 능력

    • 이 기능이 놀라운 점은, 부분적인 계정 ID 매치를 기반으로 권한을 부여하거나 거부하는 것에 정당한 이유가 없다는 것임. AWS 계정 ID는 IP 주소와 같이 민감할 수 있지만, 일을 진행하기 위해 누군가는 이를 알아야 함.

  • AWS 계정 ID == 당신의 IP 주소. 민감할 수 있지만, 일을 처리하기 위해서는 누군가가 그것을 알아야 함.

    • 예시: 작성자는 반돈세탁 절차로 인해 통합해야 하는 제3자와의 거래에서, 개방된 sftp 포트보다 일반적으로 더 안전한 privatelink 설정을 원했음. 그러나 해당 회사는 계정 ID를 숨기는 보안상의 이유로 거부함. 결과적으로, 작성자 팀은 그들이 사용하는 공개 IP 범위를 포트 22로 화이트리스트에 올림.
    • 이야기의 교훈: ID를 숨기는 것이 현명해 보일 수 있지만, 사람들이 당신에게 연락할 수 있는 주소가 없다면 실제로 비즈니스를 운영할 수 없음.

  • 일반적으로 계정 ID를 공개적으로 배포하지는 않겠지만, 어느 시점에 일부가 공개될 것으로 예상해야 함.

    • 제3자 벤더와 SaaS 플랫폼이 IAM 사용자와 액세스 키에서 역할 가정(role assumption)을 선호하는 통합 방식으로 이동함에 따라, 통합 지점으로 사용하는 계정의 계정 ID는 다른 당사자에 의해 알려지며, 그들은 자신의 의존성과 취약점을 가짐.

  • 전역 네임스페이스를 가진 다른 공개 AWS 리소스도 AWS 계정 ID를 드러냄.

    • 관심 있는 사람들을 위해, 해당 코드를 여기에 온라인으로 게시함: find-s3-account

  • 관련: AWS 키 ID(비밀 키 부분이 아님)는 계정 ID를 포함하고 있으며, 한 위치만큼 비트 이동됨.

    • 이 키 ID는 S3에 대한 사전 서명된 링크의 URL에 포함되어 있으므로, 이미 계정 ID를 공개하고 있을 가능성이 높음.

  • 흥미로운 발견이지만, 제목을 보고 더 간단한 방법이 있을 것으로 기대했음.

    • AWS에서 관리자 계정으로 "X 리소스가 어디에 있는지" 물어볼 수 있는 간단한 방법이 있었으면 좋겠음. 특히 어떤 계정에 특정 S3 버킷이 있는지 빠르게 알려주는 기능이 필요함. 이는 주로 코드로 정의되기 전에 존재했던 레거시 버킷과 관련된 문제임. 많은 AWS 계정을 가지고 있을 때 알려지지 않은 계정과 가능한 지역에서 리소스를 찾는 것은 번거로울 수 있음.

  • 실제 해킹이 "한 번에 한 문자씩 비밀번호를 '해킹'하는" 오래된 클리셰나 오해를 가져오는 시나리오는 언제나 멋짐.

  • 더 걱정되는 공격 벡터는 이제 계정 번호를 사용하여 다른 계정의 주체를 자신의 계정 정책에 허용 목록에 추가하려고 할 때임.

    • 다른 계정에 해당 주체가 존재하지 않으면 역할/사용자를 찾을 수 없는 오류가 발생함. 이를 이용하여 다른 계정의 실제 주체를 찾을 수 있음.

  • 이것이 왜 중요한가? 명백한 한 가지: 생산 버킷이 주어지면, 동일한 조직의 개발 버킷을 찾을 수 있게 되는데, 이는 예상치 못한 행동임.

답변달기