Akamai EAA 사칭 취약점 - 심층 분석

이 게시물에서는 Akamai의 EAA(Enterprise Application Access) 플랫폼에 영향을 미치는 취약점인 CVE-2021-28091의 기술 세부 사항을 다룹니다. 취약점에 대한 조사, 수정, 공개 프로세스를 소개합니다. 취약점, Akamai에 미치는 영향, EAA 고객에게 미치는 영향, 필요한 조치에 대한 개요는 함께 제공되는 부속 보고서를 참조하시기 바랍니다.

개요

이 섹션에서는 취약점의 이력과 구조에 대해 설명합니다. 일부 독자는 본 섹션을 건너뛰고 필요한 조치 섹션으로 바로 이동해, 수행해야 할 모든 평가나 향후 검토에 본 개요를 참고할 수 있습니다.

Akamai는 2016년에 Soha Systems 인수를 통해 EAA 기술을 확보하기 전에, 플랫폼 고객이 써드파티 ID 공급업체가 제공한 ID 정보를 기반으로 접속 제어 및 인증 결정을 내릴 수 있는 중요한 기능이 플랫폼에 도입되었습니다. EAA 플랫폼은 써드파티 ID 통합을 위한 다양한 방법을 제공합니다. 이 보고서에서 주목한 방법은 SAML(Security Assertion Markup Language) v2.0 인증 프로토콜을 지원한다는 것입니다.

SAML은 널리 사용되는 개방형 표준입니다. IdP(Identity Provider)는 SAML을 사용하여 서명과 반환을 암호화하고, 정의된 기간 내에 IdP에서 SP(Service Provider)로 어설션 오브젝트를 제공하는 클라이언트를 통해, SP에게 어설션할 수 있습니다. (자세한 내용은 아래의 배경 섹션을 참조하세요.)

EAA에 써드파티 IdP 지원이 추가되었을 때 개발자들은 오픈 소스 라이브러리 Lasso를 선택하여 플랫폼 내에서 SAML 지원을 구현했습니다. Akamai는 Lasso가 SP로써 자신에게 제공된 SAML 응답을 검증하는 코드를 평가한 결과, 초기 통합 단계에서 써드파티 IdP 기능을 구축하는 개발자들이 라이브러리와 함께 제공된 테스트 사례를 기반으로 합리적인 방식으로 이를 구현했다고 판단했습니다. 추가 조사 결과, Akamai를 구축하는 데 사용된 테스트 제품군이 인증 프로세스에서 사칭 취약점이나 유사한 취약점을 식별할 만큼 엄격하지는 않은 것으로 나타났습니다. 이러한 단점은 제품의 새 릴리스에 적용되는 테스트 제품군을 확장하여 유효 및 잘못 서명된 응답 및/또는 어설션과 서명되지 않은 어설션 및 응답의 모든 조합을 포함함으로써 해결되었습니다. 이러한 새로운 테스트는 앞으로 진행될 표준 QA 프로세스의 일부입니다.

보고서의 다음 섹션에서는 전반적인 취약점을 구성하는 다양한 약점과 기여 요인에 대해 자세히 설명합니다. 이러한 수준의 투명성을 제공하는 Akamai의 목표는 다른 사람들이 우리가 취한 조치를 이해하고 자신의 환경에서 유사한 상황이 발생하는 것을 피할 수 있도록 하는 것입니다.

시스템 테스트 및 평가

단위 테스트, 통합 테스트, 회귀 테스트는 모든 SDLC(Software Development Lifecycle)에서 매우 중요한 부분입니다. 구축된 하위 구성요소에는 이러한 모든 테스트 방법이 적용되었지만, 테스트가 충분히 엄격하지 않았다는 사실을 분명히 알게 되었습니다. 또한 이 인시던트로 인해, 종속성의 SDLC가 자체적으로 엄격하고 유사한 라이브러리의 취약점 같은 도메인별 발견에 의해 알려질 것이라는 잘못된 가정 하에, 일부 써드파티 라이브러리가 프로젝트에 통합될 때 간과된 부분이 드러났습니다.

구성요소와 종속성별로 엄격한 SDLC가 필요하지만, 구성요소 개발 및 QA(Quality Assurance) 계획에 통합된 테스트만으로는 충분하지 않은 경우가 많습니다. 이 테스트를 보완하기 위해 침투 테스트나 써드파티 코드 검토 같은 적대적 평가를 사용할 수 있습니다. EAA의 경우, 고객이 제품 수명 기간 동안 EAA 플랫폼에 대해 외부 보안 및 취약점 평가를 여러 차례 수행했습니다. 그럼에도 불구하고, 이 대응의 시발점이 된 보고서가 이 취약점을 Akamai에 보고한 첫 번째 사례였습니다. Akamai는 EAA 플랫폼과 클라이언트 애플리케이션의 다른 부분에 대해 집중 평가를 수행했지만 이 특정 구성요소는 해당 수준의 조사 대상이 아니었습니다.

조기 공개 방지

이 인시던트 대응 프로세스 초기에 Akamai는 높은 수준의 고객 알림을 작성하기 시작하고 동반 게시물의 필요한 조치 섹션에서 제안한 조사를 시작하도록 안내했습니다. 해당 문서의 게시 전 검토 과정에서 취약점에 대한 정보를 받지 못한 Akamai 직원에게 고객 대상 메시지의 사본이 제공되었습니다. 메시지가 제공된 지 한 시간 만에 Akamai 검토자들은 영향을 받은 프로토콜(SAML)과 영향을 받은 패키지(Lasso)를 식별할 수 있었고, Lasso 프로젝트 관리자의 최근 활동을 통해 취약점이 무엇인지 추측할 수 있었습니다. 이번 공개로 인해 책임 있는 공개 원칙을 준수하기 위한 Akamai의 부분적인 공지 계획은 즉시 중단되었습니다. 

검토자와의 추가 대화를 통해 인시던트 팀은 이러한 발견을 한 과정을 파악할 수 있었습니다. 검토자들이 보고한 주요 발견 사항은 오류 조건이 발생했을 때 IdP가 반환하는 오류 메시지였습니다. 이 취약점에 대한 수정이 릴리스될 때까지 SAML 오류는 아래 이미지에 표시된 것처럼 최종 사용자에게 Lasso 오류를 노출하는 오류 페이지를 반환합니다. 특히 인증과 같은 중요한 보안 프로세스의 경우 오류를 전달하는 것은 모범 사례에 위배되므로 이번 릴리스부터는 최종 사용자에게 오류가 표시되지 않습니다. 

위의 XML 문서는 이 보고서의 목적을 위해 단순화되었지만 구조는 동일합니다. 외부의 '상위' 문서는 요청에 대한 메타데이터와 어설션 문서를 포함하는 SAML 응답입니다. SAML 어설션이라고도 하는 어설션은 인증 프로세스에서 사용하기 위해 IdP에서 SP로 제공되는 데이터입니다. 하나의 SAML 응답에 여러 어설션이 존재할 수 있습니다. 위의 예에서 ds:Signature 괄호의 내용은 상위 오브젝트의 콘텐츠에 대한 암호화 서명이며, 이 경우 어설션입니다. 동일한 서명 오브젝트를 전체 응답 오브젝트에 적용할 수도 있습니다. 서명의 목적은 어설션이나 응답에 포함된 데이터가 정상적이고 IdP가 제공한 것이라는 것을 SP가 검증할 수 있도록 하는 것입니다. 어설션의 경우 서명은 사용자 이름, 이메일 주소 또는 그룹 구성원 표시와 같이 어설션에 포함된 모든 데이터에만 적용됩니다. 응답 수준에서 적용되는 서명은 응답의 전체 콘텐츠와 그 안에 있는 모든 어설션에 적용됩니다.

SAML 응답의 다양한 서명에 대한 확인은 SP에 맡겨지며, 애플리케이션과 통신하도록 IdP가 설정될 때 설정되는 경우가 많습니다. Akamai는 이 문제에 대응하려면 SAML 응답의 기본 확인 조건이 다음과 같아야 한다고 생각합니다.

• 전체 SAML 응답이 유효하게 서명된 경우, 응답의 모든 어설션이 올바르게 서명되었거나 서명이 없어야 합니다. 유효하지 않은 서명이 발견되면 확인에 실패해야 합니다. 이 방법은 서명된 전체 메시지 본문에 대한 권한이 있는 IdP에 의존합니다.
• SAML 응답이 서명되지 않은 경우 응답의 모든 어설션이 올바르게 서명되어야 하며, 그렇지 않으면 확인에 실패해야 합니다.
• SAML 응답에 유효하지 않은 서명이 있으면 확인에 실패해야 합니다.

위의 처리 조건은 Akamai가 Lasso에 구축을 제안한 패치입니다.

이 문제가 시작될 때 Akamai에 제공된 보고서에 따르면 연구원이 하나의 SAML 응답에 SAML 어설션 두 개를 제출했는데 첫 번째는 유효하게 서명되었지만 두 번째는 서명되지 않은 것으로 나타났습니다. Lasso의 기본 설정에는 다음과 같은 기본 확인 조건이 있습니다.

• 응답의 첫 번째 SAML 어설션이 유효하게 서명된 경우, 전체 SAML 응답 서명의 유효 여부와 관계없이 확인을 통과합니다.
• 첫 번째 SAML 어설션이 잘못 서명된 경우 확인에 실패합니다.
• SAML 응답이 유효하게 서명되었고 어설션에 서명이 없는 경우 확인을 통과합니다.
• 그렇지 않으면 확인에 실패합니다.

 문제를 더 복잡하게 만드는 것은, 라이브러리에서 응답이 유효한 것으로 간주되면 유효한 서명이 있는지에 관계없이 SAML 응답에서 어설션을 검색하는 함수가 응답 오브젝트의 마지막 어설션을 반환한다는 것입니다. 예를 들어, 공격자가 위와 같은 단일 어설션이 포함된 유효한 SAML 응답을 IdP로부터 획득한 후 두 번째 어설션으로 다음을 추가한다고 가정해 보겠습니다.

제공된 사용자가 기업에 대해 유효하지만 더 많은 권한을 가지고 있는 경우, 해당 사용자는 SP에 제출하기 위해 결합된 SAML 응답을 갖게 됩니다.

Lasso가 이 SAML 응답의 유효성을 검사하려고 시도하면 응답이 유효하다는 결과가 나옵니다. 호출 애플리케이션이 위의 응답에서 어설션을 검색하면 슈퍼유저의 사용자 ID(uid)가 포함된 어설션이 반환되고 유효한 어설션으로 간주될 가능성이 높습니다. 위의 예 외에도 SAML 응답 자체에 유효한 서명이 있는 경우 이와 동일한 방법으로 사칭할 수 있습니다. 이것은 EAA가 SAML 응답을 처리하는 경우였습니다. 

악용 조건

SP에 제출하기 전에 SAML 응답을 수정하려면 다음 조건 중 하나가 발생해야 합니다.

• 유효한 권한이 부여된 사용자가 제어하고 SAML 응답이 리디렉션되는 정상적인 클라이언트는 SAML 응답의 일부로 추가 어설션 문서를 삽입하여 SAML 응답을 변경해야 합니다. 예를 들어 클라이언트 시스템의 악성 브라우저 확장 프로그램이나 기타 멀웨어를 통해 공격이 이루어질 수 있으며 이를 "브라우저 관련(Man-in-the-Browser) 공격"이라고 합니다.
• 공격자는 어설션이 만료되기 전에 아직 시간이 있거나 일부 애플리케이션의 경우 어설션이 아직 SP에 제공되지 않았기 때문에 여전히 유효한 SAML 응답의 유효한 사본을 확보해야 합니다. 예를 들어, 중간자가 프록시를 통해 SAML 응답을 가로채서 수정할 수 있는데, 이를 "중간자(Man-in-the-Middle) 공격"이라고 합니다.
• 승인되지 않은 클라이언트는 승인된 사용자의 로그인 정보를 알고 있거나 추측할 수 있습니다. 로그인 정보는 피싱, 비밀번호 유출, 추측 또는 무차별 대입 공격 등 다양한 프로세스를 통해 수집될 수 있습니다.

위의 각 조건으로 인해 사용자 세션이 감염될 수 있으며, 위에서 언급한 것처럼 SAML 구축에 결함이 있는 경우 SP는 사칭 공격에 취약해질 수 있습니다.

취약점 기록

XML 서명 래핑으로 알려진 이 동일한 취약점은 여러 차례 그리고 반복적이면서 또한 지속적으로 보고된 바 있습니다. 

Lasso 리포지토리를 검토한 결과, 해당 라이브러리의 취약점은 라이브러리를 통합하기 훨씬 이전이자 다른 플랫폼에 발표된 이전 취약점이 공개되기 전인 2005년 11월에 코드베이스에 통합된 것으로 나타났습니다.

또한 조사 과정에서 어떤 문제에 대한 공지가 Akamai에 전달된 직후 Lasso 라이브러리 유지 관리자들이 프로젝트에 대한 커밋을 진행한 것을 발견했습니다. 보고자와 논의한 결과, 해당 커밋은 보고와 전혀 관련이 없으며 단지 우연에 의한 것이었습니다.

2021년 2월 24일에 제안된 수정 사항은 악용의 영향을 부분적으로 해결했지만, 추가 검토 결과 완전한 수정이 아니라고 판단되어 최종적으로 유지 관리자에게 패치를 제안했습니다.

Akamai의 인시던트 대응 살펴보기

Akamai는 공식적인 인시던트 대응 프로세스를 따릅니다. 인시던트는 엔지니어링/시스템 개발, 네트워크 운영 및 고객 지원 팀 직원의 협력을 통해 정기적으로 해결됩니다. 일반적으로 인시던트가 심각할수록 더 많은 사람들이 작업에 참여하여 해결해야 하며, 계획된 운영 및 작업보다 우선 순위가 높아집니다. 인시던트 발생 시 Akamai의 목표는 다음과 같습니다. 

• 문제의 영향을 제한합니다. 
• 시스템의 지속적이고 안전한 작동을 보장합니다.
• 인시던트 대응자의 지속적이고 안전한 관리를 보장합니다.
• 고객의 만족도를 유지하고 데이터를 안전하게 보호합니다.
• 다양한 법률 및 규정을 준수합니다.
• 인시던트가 발생하도록 허용한 모든 위험으로부터 배우고 개선할 수 있는지 확인합니다.

위에서 설명한 바와 같이 Akamai는 해당 취약점을 인지한 즉시 인시던트 대응 프로세스를 시작했습니다. 이 프로세스를 통해 Akamai는 기술 리소스를 조정하고, 내부 이해관계자, 경영진, 외부 이해관계자와 소통하고, 인시던트와 관련된 모든 활동을 시기적절하고 효과적인 방식으로 조정할 수 있었습니다.

패치 & 배포 프로세스

이 취약점에 대한 수정 사항을 개발하고 EAA 네트워크에 패치를 배포하는 프로세스는 계획된 업그레이드에 따르는 일반적인 프로세스와 매우 유사했지만 변경 사항이 훨씬 적고 일정이 훨씬 빨랐습니다.

인시던트 대응 몇 시간 내에 몇 가지 주요 결정을 고려하여 수정 일정 초안을 준비했습니다. 수정 사항이 준비된 후, 이 QA 프로세스는 표준 QA 프로세스에 따라 3일이 소요되고 배포 단계는 48시간이 소요될 것으로 예상되었습니다. 배포 단계 이후에는 블로그 게시물과 고객 알림의 형태로 문제를 알릴 계획을 세웠습니다. 이러한 일정은 더 앞당길 수도 있었지만, 적극적인 악용의 증거가 없었기 때문에 네트워크의 안정성을 우선시하고 전체 프로세스 동안 고객이 안정성을 유지할 수 있도록 했습니다.

엔지니어링 팀은 문제를 처음 분류한 후 서로 다른 엔지니어링 및 QA 리소스를 사용하는 두 가지 경로를 통해 수정 사항에 접근했습니다. 

한 팀은 문제에 대한 부분적인 수정을 조사하고 개발하여 보고된 문제를 종결하고, SAML 응답 처리에 대한 요구 사항을 어설션이 포함된 SAML 응답의 정상적인 표현으로 제한했습니다. 이 방법을 사용하면 일부 IdP의 응답이 유효하고 안전하더라도 일부 응답이 거부될 수 있습니다. 이 접근 방식에는 고객별로 보다 엄격한 검사를 비활성화해 소수의 IdP와 예기치 않은 상호 작용이 발생하는 경우에도 나머지 고객 기반을 보호할 수 있는 옵션도 있습니다.

다른 팀은 첫 번째 팀과 비슷한 접근 방식을 취했지만, 설정 가능한 부분 수정이 아닌 완전한 수정이라고 생각되는 작업을 수행했습니다. 이 접근 방식은 잘 형성되고 올바르게 서명된 모든 SAML 응답이 수락되도록 면밀히 검토하여 고객의 다운그레이드를 허용하는 데 필요한 복잡성을 줄였습니다.

이러한 동시 접근 방식을 채택한 이유는 하나의 경로가 차단되거나 QA 문제에 부딪히더라도 여전히 수정 사항을 배포할 수 있기 때문입니다. 미국 동부 시간으로 2월 24일 늦은 오후, 인시던트가 시작된 지 3일 후에 QA가 부분 수정을 사용할 수 있을 것으로 예상했지만 전체 수정은 개발되기까지 일주일이 더 걸릴 것으로 예상했습니다. 작업은 25일로 넘어가는 밤까지 이어졌으며, 엔지니어링 팀의 진행 보고서에 따르면 전체 수정 옵션이 잘 진행되고 개발 속도가 빠르며 테스트하기에도 복잡하지 않을 것으로 예상되었습니다.

결국 전체 수정 옵션은 부분 수정이 적용되기 약 하루 전에 QA 팀에 전달되었습니다. 첫 번째 옵션이 QA 팀에 전달된 후, 모든 EAA 고객에게 예상 배포 기간을 알리는 패치 알림이 게시되었습니다.

이 상태는 QA 프로세스를 통해 동일하게 유지되었습니다. 유지보수 기간을 약간 앞두고 전체 수정 사항이 QA 팀의 승인을 받아 배포될 수 있는 길이 열렸습니다.

배포 프로세스는 부하가 매우 적은 POP(Points of Presence)에서 시작하여 확장된 회귀 제품군을 실행하고, 고객에게 잠재적인 중단이 발생하지 않도록 트래픽을 주의 깊게 모니터링했습니다. 테스트 프로세스와 모니터링 기간을 줄이면서 부하가 적은 또 다른 POP가 업그레이드되었습니다. 3월 2일 새벽, 약 8,000명의 최종 사용자를 대상으로 더 많은 부하 테스트를 수행할 수 있도록 Akamai의 내부 EAA 배포를 지원하는 POP를 업그레이드했습니다. 그때까지 배포에 문제가 없는 것으로 확인되자 남은 36시간의 유지 관리 기간 동안 나머지 POP를 업그레이드하여 유지 관리 기간이 종료되기 전에 배포 프로세스를 완료했습니다. 

업그레이드 프로세스 중에 EAA 애플리케이션과 상호 작용하는 대부분의 사용자는 한 번 이상의 재인증 상호 작용을 경험했을 것입니다.  이 과정은 일반적으로 세션이 일시적으로 중단되고 인증 정보를 입력하기 위해 IdP로 리디렉션된 후 정상 업무로 복귀하는 방식으로 구성됩니다. EAA 클라이언트 사용자도 이 행동을 관찰했을 수 있습니다. 재인증 시도는 배포하는 동안 EAA 고객에 의해 클러스터링되었습니다. 각 POP에서 코드를 업그레이드한 후 EAA가 유지관리하는 세션 캐시가 지워졌으며, 이로 인해 5분 동안 모든 요청에 대해 재인증이 트리거되었습니다. 재인증되면 최종 사용자에게 더 이상 영향을 미치지 않는 것으로 나타났습니다.

인시던트 팀 관리

이와 같은 중요한 문제에 대한 수정 사항을 개발하고, 검증하며, 네트워크에 안전하게 배포하는 데 중요한 측면 중 하나는 문제를 해결하는 팀에 대한 세심한 배려입니다. Akamai의 인시던트 관리 프로세스 및 관련 교육에는 인시던트에 대응하는 기술 및 관리 팀의 번아웃을 제한하는 방법에 대한 지침이 포함되어 있습니다. 이 지침에는 인시던트 팀이 다음을 수행할 수 있는지 확인하는 것이 포함됩니다.

• 식사(규칙적으로)
• 수면(이상적으로는 충분한 '밤' 수면)
• 개인적인 의무 수행
• 건강 유지(코로나19 백신 접종, 운동)

당면한 인시던트를 해결하는 것도 중요하지만 전체 프로세스 동안 팀을 계속 관리하면 영향을 받은 제품 및/또는 시스템이 더 안전한 상태에 도달하는 데 도움이 되며, 피할 수 있는 오류와 종종 스트레스가 높은 인시던트 대응과 관련된 잠재적으로 고객에게 영향을 미칠 수 있는 이벤트의 수를 줄일 수 있다는 사실을 알게 되었습니다.

Akamai 인시던트 관리 프로세스의 또 다른 핵심 측면은 모두가 함께 하면서 현재나 미래에 누구도 탓하지 않는다는 원칙입니다. 인시던트 팀은 최선을 다해 문제를 해결하기 위해 협력하며, 먼저 영향을 줄이는 데 집중한 다음, 문제가 다시 발생하지 않도록 방지하는 방법을 모색합니다. Akamai는 인시던트를 일으킨 가정을 찾아내고, 이러한 불완전한 가정을 통해 학습하며, 해당 이벤트나 유사한 이벤트가 다시 발생할 가능성을 줄이기 위해 적절하게 수정하는 데 주력합니다.

필요한 조치

SAML 인증에 Lasso를 사용하는 시스템 소유자는 최대한 빨리 패치를 적용해야 합니다. 인증된 시스템에 미치는 영향을 조사하려면 추가 조치가 필요할 수 있습니다. 필요한 조치에 대한 자세한 내용은 동반 게시물의 필요한 조치 섹션에서 확인할 수 있습니다.

타임라인