해커원 버그바운티 절반의 실패 경험기

HackerOne (http://hackerone.com)은 온라인 버그바운티 플랫폼으로써 170여개의 기업이 참여하고 있다.
현재까지 45,000개 이상의 취약점이 HackerOne을 통해 보고 되었다고 하니,
해커들이 이 플랫폼을 얼마나 적극적으로 활용하고 있는지를 대략이나마 가늠할 수 있다.

해커원 버그 바운티 현황…버그가 많이도 나왔다

 

사실 시스템 해킹을 공부하는 입장에서 HackerOne 은 크게 매력적인 플랫폼은 아니다.
참여하고 있는 대부분의 기업들이 웹 어플리케이션(Web Application)을 바운티 범위 (Scope)로 잡고 있기 때문에
대부분의 보고된 취약점 역시 웹 취약점에 한정되어 있다.

그럼에도 불구하고 나는 매일같이 이 사이트를 들락날락 거리면서,
여러 해커들이 찾은 신선한 아이디어를 낼름낼름 공짜로 공부하는 즐거움을 느낄 수 있었다.

이번 블로그 포스팅은 나의 첫번째 해커원 버그바운티 도전/실패 경험 그리고
외국 보안 담당자와 우리나라 보안 담당자의 미묘한 차이에 대해 이야기 해보고자 한다.

 

무슨 취약점을 찾아 볼 것인가?

회사에서 모의해킹을 할 때에는 주어진 대상과 찾아야 하는 취약점이 명확한 경우가 많다.
그러나 해커원에 등록되어 있는 수 많은 기업들 중에서 어느 하나를 집어 취약점을 찾으려고 하니
뭔가 방법적인 면에서 비효율적이라는 생각이 들었다.
(언제 무슨 취약점이 나올지도 모르는 상황에서 끝도없이 테스트만 해보는건 너무 무모하므로…)

따라서, 최근 해커원에서 보고된 취약점 카테고리를 하나 선정한 후에
다른 사이트에서 동일한 취약점이 있는지를 점검해보는 방식으로 진행하기로 했다.

 

아마존 S3버킷 Access Control Misconfiguration 취약점

SQL 인젝션이나 XSS 같은 경우는 개인적으로 식상하기도 하고 관심사에서 멀어진 취약점이라
처음부터 고려를 하지 않았다.

최근 몇달간 해커원 사이트를 매일매일 모니터링 하면서 간간히 눈에 띄는 취약점이 하나 있었는데
바로 아마존 S3 Bucket Access Control Misconfiguration 취약점이다.
사실 이 취약점은 해킹이라 하기에는 민망할 정도로 간단하지만,
웹 서비스 환경에 따라서는 매우 Critical 할 수 있기 때문에 찾을만한 가치가 있다고 생각했다.

먼저 아마존 S3 서비스에 대해 간단히 알아보자.

아마존의 S3는 Amazon Simple Storage Service (S가 3개라서 S3….)의 약자이며,
클라우드상의 가상의 버킷을 생성하고 그 안에 데이터 객체를 유동적으로 저장할 수 있는 서비스를 의미한다.
쉽게 말해 웹에서 접속할 수 있는 클라우드 하드디스크 같은 개념으로 생각하면 이해가 쉬울 것이다.

서비스 생성하는 것도 매우 간단한데, AWS Console 에서 S3 버킷을 생성하고,
본인의 인증키로 인증한 다음 데이터를 업로드 하면 전 세계 어디서든 그 파일을 다운로드 하거나 액세스 할 수 있다.

문제는 버킷 생성 후, 해당 버킷 경로에 대한 권한 설정 부분에서 발생한다.
어떤 쇼핑몰 웹 페이지에 출력되는 이미지들이 S3에 저장되어 있다고 가정해보자.
만약 S3 버킷의 권한 설정을 잘못해서 Public User에게 Write 권한이 부여되어 있다면,
해커는 AWS 관리 도구를 통해 해당 S3버킷의 파일을 악성파일로 덮어쓰거나 새로운 파일을 마음대로 업로드 할 수 있다.

세상에 어떤 관리자가 그런 실수를 저지를까 싶겠지만,
해커원 사이트를 보다보면 이런 실수들이 꽤나 빈번하게 발생하고 있다.

실제 사례로 HackerOne 플랫폼 역시 자체적으로 버그바운티를 운영하고 있는데,
AWS S3 권한 설정을 잘못한 취약점에 대해 2,500 달러를 지급한 사례가 있었다.
⇒ https://hackerone.com/reports/128088 참조

 

Starbucks (Teavana.com) S3 취약점 분석과 검증

[Step 1] : S3 버킷 주소 탐색

S3 취약점을 찾기 위해 가장 먼저 해야할 일은 고유의 S3 버킷 주소를 찾아내는 것이다.
S3 버킷 주소는 다음과 같은 URL 형태를 가진다.

앞서 언급한 것 처럼, S3는 인터넷상의 스토리지 형태로 주로 사용되는 서비스이기 때문에
파일 다운로드 또는 외부 이미지 소스 경로로 활용되는 경우가 많다.

따라서 취약점을 분석하고자 하는 대상 웹 사이트의 HTTP Response 값을 분석하다보면,
숨겨진 S3 버킷 주소를 찾아낼 가능성이 높다.

내가 취약점 분석 대상으로 선정한 사이트는 Starbucks에서 운영하는 Teavana.com 이다.
Starbucksc.com을 비롯한 대부분의 형제사이트의 Response를 분석해보았지만
마땅한 S3 버킷 주소를 찾을 수 없었다.

그러다 스타벅스의 차(Tea)를 판매하는 Teavana.com을 분석하던 중 아래와 같은 흥미로운 S3 버킷 주소를 발견했다.

 

☞ https://www.teavana.com/us/en/gifts/starter-kits/teavana-iced-tea-starter-kit%3A-to-share-dw00206.html?navid=new-arrivals&start=5

위 URL을 접속해보면 우측 하단에 검은색 “FEEDBACK” 버튼을 볼 수 있는데,
이 버튼의 이미지 소스가 아마존 S3 버킷 주소라는것을 알 수 있다.

 

[Step 2] : AWS (Amazon Web Service) CLI 도구 설치

AWS S3 액세스 권한을 테스트 하기에 앞서 AWS CLI를 도구를 설치해야 한다.
AWS CLI 도구를 사용하면 터미널에서 명령어를 통해 AWS의 대부분 기능을 설정할 수 있다.

맥의 경우 brew를 사용, 우분투의 경우에는 apt-get 을 통해 AWS CLI를 설치할 수 있다.
설치 완료 후에 본인의 아마존 Access Key 페어 값을 넣어줘야 하는데,
이는 AWS Console 관리자 메뉴에서 확인할 수 있다. (My Security Credential 에서 발급)

[Step 3] : 공격 대상 S3 버킷으로 파일 복사 테스트

AWS CLI를 사용할 수 있는 환경이 모두 갖추어졌으므로, 공격 대상 S3 버킷에
파일 복사를 시도해보도록 하자.

테스트용 텍스트 파일을 생성한 후 아래와 같이 cli 명령어를 내리면 파일 업로드 가능 여부를 알 수 있다.

업로드에 성공했다. 즉 해당 S3 버킷은 권한 체크와 접근제어가 제대로 되어 있지 않은 상태이다.

만약 정상적으로 S3 버킷에 대한 권한 체크가 설정되어 있다면 아래와 같이 에러메시지가 표시된다.

이제 찾은 취약점을 HackerOne에 레포팅 하는 일만 남았다.

 

HackerOne 취약점 레포팅, 그리고 절반의 실패

HackerOne의 스타벅스 페이지 https://hackerone.com/starbucks 에 들어간 후,
우측 상단의 “Submit Report” 버튼을 누르면 취약점에 대한 레포트를 작성할 수 있다.

영문으로 Summary – Detail – Attack Scenario – Reference 순으로 상세하게 레포팅을 작성 후,
떨리는 마음으로 최종 제출을 하였다.

사실 제출하면서 약간은 애매한 부분이 있었는데, 내가 찾은 취약점의 포인트 (S3 URL)가
스타벅스 제품에 대한 소비자 피드백 서비스를 제공하는 서드파티 업체 (usabilla.com)에 속해있었기 때문이다.
그럼에도 제출했던 이유는 취약점 포인트가 되는 S3 이미지가 모든 사이트 페이지에서 노출이 되고 있었고,
PNG 내 스크립트 혹은 코드 인젝션을 통해 실제 접속하는 유저에게 피해를 끼칠 수 있다고 판단했기 때문이다.
(이 내용도 물론 보고서에 담았다)

그리고 며칠 후 Starbucks 보안 담당자로 부터 아래의 메일을 받았다.

요약하자면 고쳐야할 부분이 맞긴 하나, 취약한 S3 버킷의 소유자가 스타벅스가 아니기 때문에
정식 바운티로 인정하기 힘들다는 내용이었다.

 

첫번째 버그바운티로 부터 배운 것

이렇게 아쉽게도 나의 첫번째 버그바운티는 절반의 실패로 마무리되었다.
사실 버그바운티 금액을 떠나, 스타벅스로 부터 공식적인 취약점으로 인정받지 못한 것이 더 아쉬웠다.

어쩌면 한국과 외국의 업무에 대한 인식 차이일 수도 있겠다는 생각도 든다.
나도 회사 내에서 모의 해킹 업무를 수행하고 있지만, 우리는 사이트에 대한 오너쉽과 책임의 범위가 동일한 경우가 많다.

즉 서드파티의 실수로 인한 취약점이라 할지라도 오너쉽이 있으면 책임을 지는 것이 한국에선 일반적이다.
하지만, 위 사례처럼 외국은 오너쉽과 책임은 철저히 분리되어 있다는 느낌이다.

만약 내가 취약점을 레포팅할 때, 일반 유저에게 피해를 줄 수 있는 코드 인젝션으로 PoC를 했었더라도
동일한 피드백을 받았을까?… 조금은 궁금해진다.

비록 절반의 실패 혹은 성공이긴 했지만 꽤나 즐거운 경험이었다.
스타벅스 보안 담당자가 취약점이 발생한 업체의 담당자를 직접 연결해주었고,
결과적으로는 서비스를 조금 더 안전하게 만드는데 작은 일조를 했다는 보람은 느낄 수 있었다.

첫 술에 배부르랴. 이제 부터 본격적으로 버그바운티에 도전해볼까 한다.

잘 되면 와이프 맛난것도 사주고, 1석 2조이니까~!

 

참고 – 진행 경과

  • 최초 버그 발견 및 해커원 레포팅 – (2017-05-18)
  • 스타벅스 보안 담당자 1차 피드백 – (2017-05-19)
  • 스타벅스 보안 담당자 2차 피드백 – 정식 바운티 인정 불가, usabilla 담당자 연결 (2017-05-20)
  • 최종 취약점 조치 완료 (2017-05-22)

Site Footer

Sliding Sidebar

About Me

About Me

June Park