By Lily Hay Newman, WIRED US
아마존 웹 서비스(AWS) 트래픽 라우팅 서비스인 ‘애플리케이션 로드 밸런서(Application Load Balancer)’와 관련성이 있는 취약점이 해커의 접근 권한 우회, 웹 앱 보안 침해 목적으로 악용될 가능성을 경고하는 내용의 새로운 연구 결과가 발표되었다. 결함은 고객 실행 문제에서 발생했다. 소프트웨어 버그가 결함의 원인이 아니라는 뜻이다. 노출된 취약점은 AWS 사용자가 애플리케이션 로드 밸런서를 활용한 상태에서 인증 설정을 하는 방식에서 발생했다.
실행 문제는 문을 열어 두었을 때 안전 강화 조처로도 보호가 불가능한 것처럼 클라우드 보안의 중요한 구성요소에 해당한다. 보안 기업 미고(Miggo) 연구팀은 애플리케이션 로드 밸런서 인증 설정 방식에 따라 해커가 설치하고자 하는 인증 서비스를 외부 기업 인증 서비스로 교체한 뒤 피해자의 웹 앱에 접근하여 데이터를 보거나 유출할 수 있다는 사실을 발견했다.
연구팀은 공개 접근이 가능한 웹 앱을 조사한 뒤 취약점이 있는 구성 1만 5,000건 넘게 발견했다. 그러나 AWS는 연구팀이 발견한 취약점 구성 수에 반박하며, “AWS 고객 중 인증 설정 방식 때문에 구성 오류를 포함한 애플리케이션을 보유한 고객 비율은 극소수이다. 실제 취약점에 노출된 고객은 연구팀의 추산치보다 훨씬 적다”라고 주장했다. AWS는 자사의 간략한 목록에 포함된 모든 고객에게 개별로 연락하여 보안 구성을 강화하도록 안내했다고 덧붙였다. AWS는 고객 클라우드 환경에 접근하거나 볼 수 없다는 점에서 AWS가 주장하는 구성 오류가 있는 고객 수는 추산치에 불과하다.
미고 연구팀은 고객과 협업 도중 문제를 발견했다. 미고 CEO 다니엘 쉐치터(Daniel Shechter)는 “미고 연구팀은 고객 시스템에서 이상 행동을 감지했다. 인증 과정에서 무언가를 놓치기라도 한 듯 부분적으로만 완료된 사실을 발견했다. 고객과 공급사 간의 상호의존도 깊이를 보여주는 문제이다”라고 말했다.
해커가 실행 문제를 악용하려면, AWS 계정과 애플리케이션 로드 밸런서를 설정한 뒤 평소처럼 자신의 인증 토큰에 서명해야 한다. 다음 단계에서는 구성을 변경하여 피해자의 인증 서비스에서 토큰이 발행된 것처럼 속여야 한다. 이후 피해자의 시스템에서 정상적으로 생성된 것처럼 AWS에서 토큰에 서명하고는 피해자 애플리케이션 접근 권한을 손에 넣을 수 있다. 단, 공개 접근이 가능한 상태에서 구성 오류가 있는 애플리케이션이나 이미 접근 권한을 확보한 애플리케이션만 표적으로 삼아야 한다. 그러나 이 과정에서는 시스템 권한 강화가 필요하다.
AWS는 AWS 측이 애플리케이션 로드 밸런서의 취약점을 생성하는 토큰을 보지 않는다고 설명했다. 기본적으로 특정 방식으로 인증 구성을 선택하게 되는 예상 결과이기 때문이다. 2024년 4월 초, 미고 연구팀이 AWS에 문제를 처음 보고한 뒤 AWS는 구성 권고 사항 업데이트 문서를 두 차례 업데이트했다. 5월 1일 자로 배포된 첫 번째 업데이트 사항은 애플리케이션 로드 밸런서가 토큰에 서명하기 전, 인증 사항을 추가하라는 지침이 포함되었다. 7월 19일 배포된 두 번째 업데이트 사항에는 사용자에게 보안 그룹이라는 기능을 사용하는 애플리케이션 로드 밸런서만으로 트래픽을 받도록 시스템을 설정하라는 명백한 권고 사항을 추가했다.
AWS 대변인 패트릭 네이혼(Patrick Neighorn)은 와이어드에 보낸 공식 성명을 통해 “인증 요청이 없는 상태에서 구성 오류가 존재하는 고객 애플리케이션에 직접 접근할 수 있다는 점에서 해커에 의존한다는 점에서 인증이나 AWS 애플리케이션 로드 밸런서나 다른 AWS 서비스 인증 우회라고 칭하는 것은 옳지 않다. 고객에게 애플리케이션이 보안 그룹을 사용하는 애플리케이션 로드 밸런서의 요청만 수락하고, 애플리케이션 로드 밸런서의 최상의 관행을 따를 것을 권고한다”라고 전했다.
AWS의 두 가지 업데이트 사항을 종합하면, 미고 연구팀이 보고한 공격 경로를 효과적으로 다루었다. 그러나 AWS 고객이 사용 중인 시스템 설정을 변경해야 하는 방식을 포함하여 고려하면, 변경 사항은 개발자가 모든 사용자에게 배포하는 소프트웨어 패치와 다르다. 구성 오류가 있는 AWS 사용자가 업데이트된 지침을 확인하고 사용 중인 구성과 관련된 문제를 인지한 뒤 직접 변경 사항을 적용해야만 보안 문제를 개선할 수 있다.
공동 책임 모델(Shared Responsibility Model)에서는 AWS의 구성 오류와 같은 상황은 클라우드 플랫폼 공급사가 고객 보안을 위해 다루어야 하는 문제와 사용자가 스스로 관리해야 하는 대상 간 경계가 모호하다. 공동 책임 모델은 다년간 존재했으나 클라우드 서비스 고객 모두 공급사의 의도와 실제 필요한 바에 따른 정확한 보안 설정을 적용하도록 보장할 단 한 가지 확실한 해결책이 존재하지 않는 사례도 여전히 존재한다.
** 위 기사는 와이어드US(WIRED.com)에 게재된 것을 와이어드코리아(WIRED.kr)가 번역한 것입니다. (번역 : 고다솔 에디터)
<기사원문>
An AWS Configuration Issue Could Expose Thousands of Web Apps
아마존 웹 서비스(AWS) 트래픽 라우팅 서비스인 ‘애플리케이션 로드 밸런서(Application Load Balancer)’와 관련성이 있는 취약점이 해커의 접근 권한 우회, 웹 앱 보안 침해 목적으로 악용될 가능성을 경고하는 내용의 새로운 연구 결과가 발표되었다. 결함은 고객 실행 문제에서 발생했다. 소프트웨어 버그가 결함의 원인이 아니라는 뜻이다. 노출된 취약점은 AWS 사용자가 애플리케이션 로드 밸런서를 활용한 상태에서 인증 설정을 하는 방식에서 발생했다.
실행 문제는 문을 열어 두었을 때 안전 강화 조처로도 보호가 불가능한 것처럼 클라우드 보안의 중요한 구성요소에 해당한다. 보안 기업 미고(Miggo) 연구팀은 애플리케이션 로드 밸런서 인증 설정 방식에 따라 해커가 설치하고자 하는 인증 서비스를 외부 기업 인증 서비스로 교체한 뒤 피해자의 웹 앱에 접근하여 데이터를 보거나 유출할 수 있다는 사실을 발견했다.
연구팀은 공개 접근이 가능한 웹 앱을 조사한 뒤 취약점이 있는 구성 1만 5,000건 넘게 발견했다. 그러나 AWS는 연구팀이 발견한 취약점 구성 수에 반박하며, “AWS 고객 중 인증 설정 방식 때문에 구성 오류를 포함한 애플리케이션을 보유한 고객 비율은 극소수이다. 실제 취약점에 노출된 고객은 연구팀의 추산치보다 훨씬 적다”라고 주장했다. AWS는 자사의 간략한 목록에 포함된 모든 고객에게 개별로 연락하여 보안 구성을 강화하도록 안내했다고 덧붙였다. AWS는 고객 클라우드 환경에 접근하거나 볼 수 없다는 점에서 AWS가 주장하는 구성 오류가 있는 고객 수는 추산치에 불과하다.
미고 연구팀은 고객과 협업 도중 문제를 발견했다. 미고 CEO 다니엘 쉐치터(Daniel Shechter)는 “미고 연구팀은 고객 시스템에서 이상 행동을 감지했다. 인증 과정에서 무언가를 놓치기라도 한 듯 부분적으로만 완료된 사실을 발견했다. 고객과 공급사 간의 상호의존도 깊이를 보여주는 문제이다”라고 말했다.
해커가 실행 문제를 악용하려면, AWS 계정과 애플리케이션 로드 밸런서를 설정한 뒤 평소처럼 자신의 인증 토큰에 서명해야 한다. 다음 단계에서는 구성을 변경하여 피해자의 인증 서비스에서 토큰이 발행된 것처럼 속여야 한다. 이후 피해자의 시스템에서 정상적으로 생성된 것처럼 AWS에서 토큰에 서명하고는 피해자 애플리케이션 접근 권한을 손에 넣을 수 있다. 단, 공개 접근이 가능한 상태에서 구성 오류가 있는 애플리케이션이나 이미 접근 권한을 확보한 애플리케이션만 표적으로 삼아야 한다. 그러나 이 과정에서는 시스템 권한 강화가 필요하다.
AWS는 AWS 측이 애플리케이션 로드 밸런서의 취약점을 생성하는 토큰을 보지 않는다고 설명했다. 기본적으로 특정 방식으로 인증 구성을 선택하게 되는 예상 결과이기 때문이다. 2024년 4월 초, 미고 연구팀이 AWS에 문제를 처음 보고한 뒤 AWS는 구성 권고 사항 업데이트 문서를 두 차례 업데이트했다. 5월 1일 자로 배포된 첫 번째 업데이트 사항은 애플리케이션 로드 밸런서가 토큰에 서명하기 전, 인증 사항을 추가하라는 지침이 포함되었다. 7월 19일 배포된 두 번째 업데이트 사항에는 사용자에게 보안 그룹이라는 기능을 사용하는 애플리케이션 로드 밸런서만으로 트래픽을 받도록 시스템을 설정하라는 명백한 권고 사항을 추가했다.
AWS 대변인 패트릭 네이혼(Patrick Neighorn)은 와이어드에 보낸 공식 성명을 통해 “인증 요청이 없는 상태에서 구성 오류가 존재하는 고객 애플리케이션에 직접 접근할 수 있다는 점에서 해커에 의존한다는 점에서 인증이나 AWS 애플리케이션 로드 밸런서나 다른 AWS 서비스 인증 우회라고 칭하는 것은 옳지 않다. 고객에게 애플리케이션이 보안 그룹을 사용하는 애플리케이션 로드 밸런서의 요청만 수락하고, 애플리케이션 로드 밸런서의 최상의 관행을 따를 것을 권고한다”라고 전했다.
AWS의 두 가지 업데이트 사항을 종합하면, 미고 연구팀이 보고한 공격 경로를 효과적으로 다루었다. 그러나 AWS 고객이 사용 중인 시스템 설정을 변경해야 하는 방식을 포함하여 고려하면, 변경 사항은 개발자가 모든 사용자에게 배포하는 소프트웨어 패치와 다르다. 구성 오류가 있는 AWS 사용자가 업데이트된 지침을 확인하고 사용 중인 구성과 관련된 문제를 인지한 뒤 직접 변경 사항을 적용해야만 보안 문제를 개선할 수 있다.
공동 책임 모델(Shared Responsibility Model)에서는 AWS의 구성 오류와 같은 상황은 클라우드 플랫폼 공급사가 고객 보안을 위해 다루어야 하는 문제와 사용자가 스스로 관리해야 하는 대상 간 경계가 모호하다. 공동 책임 모델은 다년간 존재했으나 클라우드 서비스 고객 모두 공급사의 의도와 실제 필요한 바에 따른 정확한 보안 설정을 적용하도록 보장할 단 한 가지 확실한 해결책이 존재하지 않는 사례도 여전히 존재한다.
** 위 기사는 와이어드US(WIRED.com)에 게재된 것을 와이어드코리아(WIRED.kr)가 번역한 것입니다. (번역 : 고다솔 에디터)
<기사원문>
An AWS Configuration Issue Could Expose Thousands of Web Apps
저작권자 © WIRED Korea 무단전재 및 재배포 금지
저작권자 © WIRED Korea 무단전재 및 재배포 금지
이 기사를 공유합니다