25K AWS S3 버킷 탐색

AWS S3 버킷의 권한 문제는 서비스 자체만큼 오래되었습니다. 이 문제에 대해 가장 잘 알려진 두 가지 연구는 Skyhigh가 모든 S3 버킷의 7 %가 열려 있다고 지적하고 Rapid7은 17 %가 열려 있다고 지적했다고 생각합니다. 오늘 우리는 2018에 있으며 문제의 현재 상태를 확인하기로 결정했습니다. 또한, 나는 그러한 연구를 수행하는 기술을 제시하고 싶습니다. 만약 영리한 것을 놓친 경우 의견에 알려주십시오.

몇 가지 이론으로 시작합시다

다음 URL을 사용하여 모든 AWS S3 버킷에 액세스 할 수 있습니다.

https : // [bucket_name] .s3.amazonaws.com /
https : // [aws_endpoint] .amazonaws.com / [bucket_name] /

또는 AWS CLI를 사용하는 경우 :

$ aws s3 ls --region [region_name] s3 : // [bucket_name]

종종 사람들은 지역 매개 변수를 사용해야 할 필요가 없습니다. 그러나 일부 버킷은 지역을 지정하지 않으면 작동하지 않습니다. 작동 할 때와 패턴이 보이지 않을 때는 항상이 매개 변수를 추가하는 것이 좋습니다. :)

따라서 일반적으로 유효한 버킷을 찾는 것은 s3.amazonaws.com 또는 [aws_endpoint] .amazonaws.com의 하위 도메인을 찾는 것과 같습니다. 아래에서는이 작업에 도움이 될 수있는 4 가지 방법을 살펴 보겠습니다.

무차별

각 버킷 이름은 고유해야하며 몇 가지 예외를 제외하고 3 ~ 63 자의 영숫자 문자 만 포함 할 수 있습니다 ( '-'또는 '.'는 포함 할 수 있지만 시작하거나 끝날 수는 없습니다). 즉, 우리는 모든 S3 버킷을 찾을 수있는 충분한 지식을 갖추고 있지만 솔직히 말하면 짧은 이름에는 효과가있을 것입니다. 그럼에도 불구하고 사람들은 명명에 몇 가지 패턴을 사용하는 경향이 있습니다. [company_name] -dev 또는 [company_name] .backups. 특정 회사의 버킷을 검색하면 LazyS3 또는 aws-s3-bruteforce와 같은 도구를 사용하여 잘 알려진 패턴을 확인하는 프로세스를 쉽게 자동화 할 수 있습니다. Rzepsky라는 회사가 있다고 가정하겠습니다. 간단한 명령 : $ ruby ​​lazys3.rb rzepsky는 rzepsky-dev 버킷을 나타냅니다.

그러나 특정 이름없이 가능한 많은 버킷을 수확하려면 어떻게해야합니까? 이 게시물을 계속 읽으십시오.)

웨이 백 머신

Wayback Machine에 대해 들어 본 적이 있습니까? 인용 위키 백과 :

Wayback Machine은 월드 와이드 웹 (World Wide Web)의 디지털 아카이브 및 인터넷 아카이브가 만든 인터넷의 기타 정보입니다.

이 디지털 아카이브의 일부 리소스는 Amazon 인프라에 저장됩니다. 즉, Wayback Machine이 S3 버킷에서 하나의 사진 만 인덱싱 한 경우이 정보를 검색하여이 버킷에 퍼블릭 리소스가 포함되어 있는지 확인할 수 있습니다. 인덱싱 된 사진이 이미 제거되었거나 액세스가 거부 된 경우에도 버킷 이름이 남아 있으므로 흥미로운 파일을 찾을 수 있습니다. Wayback Machine의 API를 요청하려면 enum_wayback이라는 Metasploit 모듈을 사용할 수 있습니다.

이 게시물의 시작 부분에서 기억할 수 있듯이 리전 사양의 URL을 사용하여 버킷의 내용을 참조 할 수도 있습니다. 따라서 더 나은 결과를 얻으려면 간단한 bash one-liner로 가능한 모든 Amazon S3 엔드 포인트의 하위 도메인을 확인할 수 있습니다.

-r 영역을 읽는 동안 $; msfconsole -x "\ 보조 / 스캐너 / http / enum_wayback 사용; DOMAIN $ region 설정; \
OUTFILE 설정 $ region.txt; 운영; 종료 "; 완료 

Wayback Machine은 종종 하나의 버킷에 배치 된 수천 장의 사진을 제공합니다. 따라서 유효하고 고유 한 버킷 이름 만 가져 오려면 일부 작업을 수행해야합니다. cut 및 awk와 같은 프로그램은 여기서 좋은 친구입니다.

Wayback Machine은 398,7MB txt 파일 형식의 23498 개의 잠재적 버킷을 제공했습니다. 이 버킷 중 4863 개가 공개적으로 개방되었습니다.

타사 쿼리

내가 소개하고 싶은 또 다른 기술은 Google, Bing, VirusTotal 등과 같은 타사에 쿼리하는 것입니다. 외부 서비스에서 흥미로운 정보를 수집하는 프로세스를 자동화 할 수있는 많은 도구가 있습니다. 그중 하나가 Sublist3r입니다.

다시 한 번, 각 지역의 하위 도메인을 검색 한 다음 고유 버킷 이름 만 가져와야합니다. 빠른 강타 원 라이너 :

-r 영역을 읽는 동안 $; python3 sublist3r.py -d $ region \
> $ region.txt; 완료 

결과는 756으로 나타납니다. 단 하나의 버킷 만 수집 할 수있었습니다. 관리자를위한 맥주!

인증서 투명성 로그에서 검색

마지막으로 제시하고자하는 기술은 인증서 투명성 로그를 보면서 버킷 이름을 검색하는 것입니다. 인증서 투명성에 익숙하지 않은 경우이 프레젠테이션을 시청하는 것이 좋습니다. 기본적으로 발급 된 모든 TLS 인증서가 기록되고 모든 해당 로그에 공개적으로 액세스 할 수 있습니다. 이 아이디어의 주요 목표는 실수로 또는 악의적으로 사용 된 인증서가 없는지 확인하는 것입니다. 그러나 공개 로그라는 아이디어는 S3 버킷도 포함하여 모든 도메인을 보여줍니다. 좋은 소식은 버킷 스트림이라는 검색 도구를 이미 사용하고 있다는 것입니다. 더 좋은 소식은이 도구가 발견 한 버킷에 대한 권한도 확인한다는 것입니다. 자, 한번 봅시다 :

$ python3 bucket-stream.py-스레드 100 --log

571134 가능성을 확인한 후 버킷 스캐너는 398 개의 유효한 버킷을 반환했습니다. 그들 중 377 명이 공개되었습니다.

버킷의 내용 확인

자, 우리는 수천 개의 버킷 이름을 찾았으며 다음은 무엇입니까? 예를 들어 이러한 버킷 중 어느 것이 퍼블릭 또는 인증 된 AWS 사용자 (기본적으로 퍼블릭과 동일한) 액세스를 허용하는지 확인할 수 있습니다. 이를 위해 내 스크립트 BucketScanner를 사용할 수 있습니다.이 도구는 액세스 가능한 모든 파일을 나열하고 버킷에 대한 쓰기 권한도 확인합니다. 그러나이 연구의 목적으로 다음과 같은 방식으로 bucket_reader 메소드를 수정했습니다.

데프 bucket_reader (bucket_name) :
    지역 = get_region (bucket_name)
    region == '없음'인 경우 :
        패스
    그밖에:
        버킷 = get_bucket (bucket_name)
        결과 = ""
        시험:
            bucket.objects.all ()의 s3_object의 경우 :
                s3_object.key 인 경우 :
                    "{0}을 (를) 수집 할 수 있습니다".format (bucket_name)
                    결과 = "{0} \ n".format (bucket_name)
                    append_output (결과)
                    단절

버킷에서 하나의 파일 만 수집 할 수있는 경우에는 작업을 수행하는 것이 가장 우아한 방법은 아니지만 수정 된 스캐너는이 버킷을 수집 가능한 것으로보고합니다.

위험

공개적으로 액세스 할 수있는 파일 중에서 정말 흥미로운 파일을 찾을 수 있습니다. 그러나 민감한 데이터 유출이 유일한 위험은 아닙니다.

일부 버킷은 공개적으로 쓸 수 있습니다. 침입자는 이러한 버킷을 맬웨어 배포 지점으로 사용할 수 있습니다. 합법적 인 소프트웨어를 직원들에게 배포하기 위해 이러한 버킷을 사용하는 경우 훨씬 더 무섭습니다. 이러한 시나리오를 상상해보십시오. 모든 신규 이민자를 회사 버킷에서 소프트웨어를 설치하도록 안내하고 있으며이 소프트웨어는 이미 감염된 설치 관리자. 이 시나리오의 다른 변형은 S3 연구원을 트롤링하는 것입니다. “Salary report — 2017.pdf”와 같이 유혹적인 이름으로 감염된 파일을 업로드함으로써 (물론 모든 책임 연구원은 신뢰할 수없는 파일을 항상 샌드 박스 환경에 다운로드합니까?)

공개적으로 쓸 수있는 버킷의 또 다른 위험은 모든 데이터를 잃을 수 있다는 것입니다. 버킷 객체에 대한 DELETE 권한이 없지만 쓰기 권한 만 있어도 파일을 덮어 쓸 수 있습니다. 즉, 빈 파일로 파일을 덮어 쓰면이 파일을 더 이상 사용할 수 없음을 의미합니다. 이 예를 살펴 보겠습니다.

이러한 시나리오에서 데이터를 저장할 수있는 유일한 메커니즘은 버전 관리를 활성화하는 것입니다. 그러나이 메커니즘은 비용이 많이 들며 (버킷에서 사용 된 공간의 크기를 두 배로 늘림) 많은 사람들이 사용하지 않기로 결정합니다.

나는 또한 논쟁을 들었다.

오, 테스트 목적으로 만 사용하십시오.

"테스트"버킷이 불법 컨텐츠의 저장 공간이되면 ... 죄송합니다.하지만이 계정에 고정 된 신용 카드입니다.

더 밝은 미래?

S3 버킷 권한 관련 문제는 여전히 존재하며 가까운 시일 내에 큰 변화가 없을 것으로 예상됩니다. IMHO 직원은 항상 작동하기 때문에 공개 액세스 권한을 부여합니다. S3 서비스가 다른 서비스와 협력 할 때 권한을 지정하는 것에 대해 걱정할 필요가 없습니다. 다른 이유는 권한 구성 (예 : 버킷 정책에서 "*"문자를 잘못된 위치에 배치)이나 사전 정의 된 그룹 (예 : "인증 된 모든 AWS 계정"그룹은 AWS를 통해 여전히 설정 될 수 있음)을 이해하지 못하는 단순한 실수 일 수 있습니다. CLI).

또 다른 문제는 그러한 문제를보고하는 방법입니다. 버킷에 고정 된 이메일이 없으므로 누구에게 연락해야하는지 확신 할 수 없습니다. 버킷 이름은 회사 X에 속해 있음을 나타낼 수 있지만 누구나 이름을 느슨하게 지정할 수 있습니다. 그래서 트롤러를 조심하십시오!

요약

24652 스캔 버킷의 경우 5241 버킷 (21 %)에서 파일을 수집하고 1365 버킷 (6 %)에 임의의 파일을 업로드 할 수있었습니다. 결과에 따르면 의심의 여지없이 문제가 여전히 존재한다고 말할 수 있습니다. 일부 버킷은 의도적으로 열리지 만 (예 : 일부 사진, 회사 브로셔 등을 제공) 공개적으로 쓸 수있는 것은 아닙니다. 더 많은 버킷을 찾는 다른 멋진 방법이 있다고 확신합니다. 따라서 합당한 유일한 대책은 ... 버킷에 올바른 권한을 설정하는 것 같습니다.

AWS Kingdom SecuRing에 대한 7 단계 안내서도 찾아보십시오.