공유된 인증정보가 보안 유출의 문을 열다
목차
서론
현대 사회가 기술에 의존함에 따라 기술 전문가와 일반 대중 모두 은행 로그인 포털, 오픈 소스 소프트웨어, 심지어 운영 체제 자체를 통해서든 타인의 코드에 의존하게 되었습니다. 그리고 일관성과 실용성이 요구되는 상황 속에서 코드 라이브러리와 같은 것이 탄생했습니다. 모든 코드를 처음부터 작성하는 것은 확장성이 없기 때문입니다.
환경이 복잡해질수록 이미 존재하는 툴을 어떤 영역에서 자동화하고 재사용할 수 있는지 찾아야 합니다.
그러나 개발자가 이러한 사전 구축된 라이브러리의 코드를 자신의 코드 기반으로서 사용할 때 “신뢰 문제”가 발생합니다. 즉, 이러한 코드 사용에는 보안 전문가가 위험하다고 판단할 수 있는 수준의 신뢰가 요구됩니다. 취약점이 소스 코드의 깊은 곳에 숨어 있을수록 발견하기 어려워집니다. 게다가 이는 애초에 모래사장 속에서 디지털 바늘을 찾아야 한다는 것을 전제할 때의 이야기입니다.
Akamai는 자체 개발 과정에서 이러한 '신뢰 문제'를 경험했습니다. 겉보기엔 평범하고 일상적인 외부 서비스 사용을 통해 여러 심각한 공격 가능성이 발견되었습니다. 이에 따라 해당 정보를 벤더사에 공개했으며, 이후 식별된 문제는 해결되었습니다. 이 블로그 게시물에서는 Akamai가 발견한 내용, 발견 과정 그리고 공격자가 이를 악용할 수 있는 방법을 논의합니다.
살펴보기
정기적인 최적화 테스트 중, Akamai 팀의 DevOps 엔지니어 중 한 명이 써드파티 테스트 툴용으로 새로운 컨테이너를 생성했고, 매우 익숙한 명령어인 apt get update && apt get install XXXX -y를 실행했습니다.
명령어를 입력한 후, 컨테이너 생성 과정 중 엔드포인트에서 실행 중인 내용을 확인하고 싶었습니다. 이를 위해 엔드포인트에서 간단한 프로세스 목록 명령어 ps 를 실행했으며, 다음과 같이 매우 흥미로운 줄을 발견했습니다.
식별된 인증정보를 사용해 수백 개의 고객 빌드가 포함된 사이트에 인증할 수 있었던 것입니다.
순수한 텍스트 키가 존재한다는 사실이 우려스러웠지만, 적절한 사용자 제어(예: 앱 사용 시마다 토큰 생성)가 있었다면 그 존재 이유가 설명되거나 키를 통제할 수 있었을 것입니다. 그러나 이 경우 그렇지 않았습니다. 제공된 사용자 이름에 “default”라는 문자열이 포함되어 있었고, 이는 결코 좋은 신호가 아닙니다.
Akamai는 조금 더 깊이 조사하기로 결정하고 인증정보를 사용해 API에 인증을 시도했습니다. 이를 통해 민감할 수 있는 정보를 쿼리할 수 있었고 그 규모 또한 매우 컸습니다. 결과적으로 “default” 사용자는 실제로 매우 기본적인 사용자였습니다. 즉, 이 사용자는 Akamai 전용으로 지정된 것이 아니라 해당 애플리케이션의 전체 고객층에서 사용되는 사용자였던 것입니다.
이 평문 비밀 정보를 확보한 공격자는 내부 테스트 실행 결과, 동영상 녹화 파일, 스크린샷, 내부 스크립트 실행 흐름 등 해당 애플리케이션을 사용하는 고객 대부분의 민감한 데이터를 조회할 수 있었습니다(그림 1).
Fig. 1: Example of improperly accessed sensitive customer data
엄청난 양의 데이터가 노출됐고 취약점이 명백했기 때문에 Akamai는 코드베이스를 더 깊이 조사하고 다른 취약점도 찾아보기로 했습니다.
공유가 항상 배려인 것은 아닙니다
Akamai는 애플리케이션에서 심각하게 오용되고 있는 공유 비밀 정보를 식별한 후, 다른 유사한 비밀 정보를 찾아보기로 결정했습니다. 그리고 애플리케이션의 소스 코드 내에서 몇 번의 전략적인 검색(그리고 많은 정리 작업)을 통해 다음 3개의 추가 비밀 정보를 발견했습니다.
- Coralogix 프라이빗 키
- Google API 키
- ngrok 토큰
이제 각 비밀 정보와 그 악용 가능성을 살펴보겠습니다.
Coralogix: 실제로는 매우 퍼블릭한 프라이빗 키
애플리케이션의 코드베이스에서 발견한 비밀 정보 중 하나는 프라이빗 키였습니다. Akamai는 여기에 관심을 갖고 해당 프라이빗 키와 연결될 수 있는 사용자 이름을 찾아봤습니다. 그리고 그 키로부터 몇 줄 아래에서 로깅 기능 안에 포함된 사용자 이름을 발견했습니다. Akamai는 남겨진 다른 단서를 활용해 프라이빗 키가 Coralogix 로깅 프레임워크에 속한다는 것을 확인했습니다.
인증정보는 하드코딩되어 있었으며, 이는 다른 고객들과 공유되고 있음을 의미합니다. 또 다른 데이터 유출 가능성이 있었지만, 다행히 이 사용자/공격자는 권한이 낮아서 프레임워크 내 로그 메시지를 작성하는 것 외의 작업을 실행할 수 없었습니다.
쓰기 프리미티브는 이전의 프리미티브보다 강하지는 않더라도 벤더사에게 있어 주목할 만한 공격 기법이 될 수 있습니다. 공격자는 벤더사 환경에 위조된 로그 메시지를 삽입하거나 악성 로그를 주입해 XSS(Cross-Site Scripting) 또는 SQL(Structured Query Language) 주입과 같은 공격을 시도할 수 있습니다.
Google API 키
OAuth는 Google의 모든 서비스에서 사용되는 인증 메커니즘입니다. 애플리케이션과 사이트는 사용자가 OAuth와 연동된 Google 계정으로 로그인하도록 허용할 수 있습니다. 이 옵션을 코드를 통해 활성화하려면 개발자는 Google 계정에서 얻을 수 있는 몇 가지 매개변수가 필요합니다. 즉, API 키인 google_name 및 google_secret이 필요합니다.
Akamai는 코드를 검토하던 중 Google API에 대한 참조를 발견했습니다. 일반적으로 “google api” 키를 볼 때는 해당 키만 표시되지만 이번에는 달랐습니다. 이번에는 “google api” 키, google_client 고유 식별자, 그리고 (가장 놀랍게도!) google_secret 식별자도 발견된 것입니다. 이 세 가지를 모두 보유한 공격자는 벤더사로 위장해 Google의 인증 링크를 요청할 수 있습니다. 공격자는 이 링크를 피싱 캠페인의 일부로 사용해 피해자를 속이고 Workspace에 대한 권한을 받을 수 있습니다.
피싱 악용 가능성
공격자는 벤더사의 사이트와 동일하게 보이는 사이트로 연결되는 링크를 포함한 피싱 이메일을 생성할 수 있습니다. 하지만 여기에는 한 가지 중요한 차이가 있습니다. 이 Google 로그인 링크는 공격자가 벤더사의 Google API 세부 정보를 사용해 얻은 링크라는 점입니다(그림 2).
Fig. 2: Malicious Google login page appears to be legitimate
로그인 시 피해자는 공격자에게 전체 Google Workspace 계정에 대한 권한을 부여합니다. Google ID와 같은 민감한 정보에 접속할 수 있다면 공격자의 가능성은 무궁무진합니다. 공격자는 악용에 성공하면 이메일 감염, 파일 다운로드 등을 포함해 피해자의 Google Workspace 계정 모든 측면을 조작할 수 있습니다. 이는 기업을 대상으로 한 소셜 엔지니어링 공격으로 사용할 때 매우 유용할 수 있습니다.
ngrok
네트워크 터널링은 안전한 데이터 전송에 거의 보편적으로 사용되는 솔루션으로, 감염될 경우 공격자에게 악용 기회를 가득 담은 보물 상자가 될 수 있습니다. Akamai는 감염된 애플리케이션을 설치하는 과정에서 ngrok 설정과 같은 터널링 관련 매개변수를 다수 발견해 추가 조사를 진행하게 되었습니다. 개발자 간 협업을 용이하게 하는 바로 그 기능이 공격자에게는 매력적인 요소로 작용하는 것입니다.
ngrok은 서버를 통해 정보를 터널링하는 플랫폼을 제공하는 서비스입니다. ngrok으로 매우 간단히 서비스를 인터넷에 노출시켜 디버깅을 가속하고 개발 피드백 루프를 효율화할 수 있습니다. 불행히도 공격자가 터널을 제어하는 순간 이 단순함은 공격자도 이용할 수 있게 됩니다.
공격자는 단순한 ps 명령어를 실행함으로써 기업의 고유 ID와 인증 토큰을 확인할 수 있습니다. 이 고유 ID는 변경 불가능하며, 다른 엔드포인트에서 해당 애플리케이션을 사용할 때도 동일하게 유지됩니다. 공격자는 이러한 매개변수로 ID와 토큰을 벤더사의 온라인 서버로 전송해 기업의 ngrok 세부 정보를 얻을 수 있습니다(그림 3).
Fig. 3: Ngrok token received from the vendor’s server
즉, 공격자는 최초 접속 후 피해자의 고유 ID와 토큰을 복사해 피해자의 애플리케이션에서 전송되거나 수신되는 데이터를 읽을 수 있습니다 (그림 4).
Fig. 4: Example of data being read from ngrok tunnel
결론
위협은 외부에서만 발생하는 것이 아닙니다. 실제로 Akamai는 일부 위협이 내부에서 발생한다고 인정합니다. 많은 사람들이 오픈 소스 소프트웨어가 신뢰를 많이 받기 때문에 오픈 소스가 가장 큰 위험이라고 생각하지만 써드파티 툴이 오픈 소스보다 기업에 더 큰 도전 과제가 될 수 있습니다.
Akamai는 취약점을 발견한 후 영향을 받는 벤더사에게 여기서 살펴본 문제를 공개했으며 해당 문제는 수정되었습니다. 그럼에도 불구하고 새로운 보안 취약점은 항상 가까이 있습니다.
Akamai는 이 사례는 물론 다른 많은 사례에서도 보안 감독 이 개발자에게 보안 의식을 갖도록 교육하는 것만큼 중요하다고 믿습니다. 이 두 가지는 매니지드 서비스가 기업에 문제를 일으키지 않도록 보장하는 데 도움이 될 수 있습니다.