Google은 developers.google.com과 기타 문서 사이트를 지원하는 공유 플랫폼인 DevSite에서 문서화되지 않은 원격 코드 실행 취약점을 발견한 보안 연구원 Simon Köck에게 9만 달러의 보상금을 지급했다. Köck은 8월 6일 문제를 제보했고 Google은 다음 날 보고서를 접수했으며 8월 27일 보상금 지급에 동의했지만, 수정 사항은 10월 7일 서버에 적용됐다.
Google은 이 취약점을 자사의 심각도 측정 기준에서 가장 높은 수준인 S0으로 분류했다. 또한 일반 애플리케이션 계층의 RCE 취약점에 대한 기본 보상금 7만 5천 달러에 보고서의 탁월한 품질을 이유로 20%를 추가해 Köck에게 지급했다.
세 가지 오류가 익스플로잇 체인을 구성했다
DevSite은 폐기된 oauth2client 라이브러리의 직렬화된 OAuth2WebServerFlow 객체를 Flask 세션 쿠키에 저장하고 있었다. 이로 인해 OAuth 클라이언트 시크릿이 노출됐지만, 해당 시크릿이 Flask 세션 서명 키로도 사용되면서 문제는 더욱 심각해졌다.
Köck은 로컬에서 쿠키 서명을 재현하고 서버가 받아들이는 위조 세션을 생성할 수 있었다. OAuth 흐름이 세션 데이터의 역직렬화에 pickle을 사용했기 때문에, 서명된 악성 pickle 페이로드로 객체를 교체한 뒤 원격 Python 코드 실행을 입증할 수 있었다.
연구원은 sleep 명령을 통해 응답을 지연시키는 페이로드를 사용해 실행을 확인했으며, 실제 명령을 실행하거나 파일, 자격 증명 또는 내부 서비스에 접근하기 전에 의도적으로 중단했다. 그의 설명에 따르면 위조 세션은 영향을 받은 7개 도메인에서 모두 허용됐고, 개념 증명 테스트는 developers.google.com, docs.partner.android.com, web.dev 등 3개 도메인에서 수행됐다.
영향 범위는 완전히 확인되지 않았다
Köck은 서버가 Google 문서 콘텐츠를 수정하거나 설치 명령과 다운로드 링크를 교체할 수 있는지는 입증하지 못했다. 이는 소프트웨어 공급망 공격으로 이어질 수 있는 시나리오였다. 또한 위조 세션으로 사용자를 사칭하거나 사용자 데이터에 접근할 수 있는지도 테스트하지 않았다.
@brutecat으로 알려진 연구원 Arvin Shivram은 내부 App Engine 애플리케이션이 일반적으로 Google의 서비스 간 내부 통신 시스템인 Stubby에 접근할 수 있다고 지적했다. Köck은 이 프로세스에 그러한 접근 권한이 있었다면 영향이 크게 확대될 수 있다고 말했지만, DevSite의 권한이나 백엔드 서비스에 대한 접근 범위는 확인하지 못했다.
이 소식이 중요한 이유
이번 사례는 위험이 단일 오류에서 비롯된 것이 아니라 세 가지 관행의 결합에서 발생했음을 보여준다. 즉, 민감한 시크릿을 쿠키에 노출하고 이를 서명 키로 재사용했으며 신뢰할 수 없는 데이터에 안전하지 않은 역직렬화를 적용했다. 이 사슬에서 어느 한 고리라도 수정했다면 익스플로잇 경로를 차단할 수 있었으므로, 시크릿을 분리하고 세션 데이터에서 pickle을 거부하는 것은 선택적 개선이 아니라 기본적인 통제 조치다.
반면 약 두 달에 걸친 수정 기간은 Google이 답하지 않은 운영상의 의문을 제기한다. 회사는 임시 완화 조치를 적용했는지, Köck이 7개 도메인에서 사용한다고 밝힌 서로 다른 두 서명 키를 교체했는지, 기존 세션을 무효화했는지를 설명하지 않았다. 또한 패치 공개 전에 취약점이 악용됐을 가능성에 대한 포렌식 결과도 공개하지 않았으며, 기사 업데이트 시점까지 The New Stack의 논평 요청에 답하지 않았다.
뉴스 출처
The New Stack - Software Development
원문 보기 ↗