DevSecOps: 낡은 보안 버그가 부리는 새로운 재주

원문 출처: DevOps.com.

사이버 보안 분야에서 우리는 종종 사냥꾼과 같습니다. 눈은 항상 지평선을 향해 고정되어 있고, 다음에 터질 취약점(과 이를 막기 위한 적절한 설계 도구, 기술 및 전술)을 찾느라 여념이 없습니다. 하지만 이러한 미래 지향적 시각은 역설적으로 전반적인 보안 인식을 약화시켜, 우리 주변에 깊숙이 자리 잡고 공격자들이 호시탐탐 노리는 위험을 보지 못하게 만들 수 있습니다.

저는 현대 사이버 보안을 종종 케블라 방탄복에 비유하곤 합니다. 케블라의 신비로운 특성은 고속 탄환과 온갖 강력한 현대 무기를 막아낼 수 있습니다. 착용자는 자신이 무적이라고 느낄지도 모릅니다. 하지만 기원전 1000년경에 처음 만들어진 고대 무기인 활과 화살은 종종 그 방어력을 뚫어버립니다. 돌 다음으로 세상에서 두 번째로 오래된 무기인 날카로운 칼은 케블라를 마치 면 티셔츠를 찢듯 쉽게 베어버릴 수 있습니다. 게다가 케블라가 인체의 모든 부분을 완벽하게 보호할 수 없다는 점도 문제입니다. 공격자가 치명타를 입힐 수 있는 작은 틈만 발견한다면, 소프트웨어의 취약한 부분처럼 그곳을 파고들 것입니다.

사이버 보안 분야의 많은 조직도 마찬가지로 8~10년 된 시스템의 결함에 취약합니다. 현대 컴퓨팅 환경에서 이 정도 연식이면 은퇴를 앞둔 노병이나 다름없죠. 하지만 이런 노후 시스템의 결함이 무해하다고 생각한다면, 조만간 '죽음의 블루스크린'을 마주하게 될지도 모릅니다.

노병에게 찾아온 취약점

가장 오래되고 널리 사용되는 자바스크립트 라이브러리 중 하나인 jQuery는 이벤트 처리부터 DOM 트리 탐색 및 조작, 애니메이션 생성에 이르기까지 모든 것을 지원하는 오픈 소스 리소스입니다. 수년간 사용되어 온 든든한 일꾼이죠. 사람들은 이 라이브러리가 워낙 오랫동안 검증되었으니 모든 취약점이 제거되었을 것이라고 지레짐작합니다.

안타깝게도 현실은 그렇지 않습니다. 기본적으로 jQuery에 의존하는 대부분의 애플리케이션은 인증을 위해 라이브러리 내부 지침을 사용합니다. 예를 들어 Apache 서버의 경우 .htaccess 파일을 확인하는 방식입니다. Apache를 사용하는 프로그램을 설계하는 개발자 중 Apache 서버 업데이트에 .htaccess 관련 내용이 포함되었는지 확인하는 사람은 거의 없을 것입니다. 애초에 수년간 보안의 근간이었던 핵심 구성 요소를 Apache가 왜 제거하겠냐고 생각하기 때문이죠.

이상하게 들리겠지만, Apache는 버전 2.3.9에서 정확히 그렇게 했습니다. 프로그램이 실행될 때마다 .htaccess 구성 파일을 확인하는 과정이 성능을 저하시킨다는 이유였습니다. 이를 제거하여 Apache 성능은 향상되었지만, 대부분의 사람이 알지 못하는 취약점이 생겨났습니다. 개발자들이 자신의 앱이 여전히 .htaccess 파일에 접근할 수 있는지 확인하지 않는다면, 대부분의 요청은 검증 없이 그대로 수락될 것입니다.

최근 전문가들은 이 결함을 발견하고, 이를 악용하면 권한이 없는 사용자가 보안이 유지되어야 할 시스템에 셸이나 거의 모든 유형의 코드를 업로드하고 실행할 수 있다는 점을 지적했습니다. 이로 인해 10월에 CVE-2018-9206이라는 취약점 경고가 발표되었습니다. 하지만 보안 연구원이 이 결함을 쉽게 발견했다는 사실은, 취약점 탐색만을 전문으로 하는 해커들은 이미 이를 알고 있었을 가능성이 높음을 시사합니다. 실제로 공개적인 패치와 수정 작업이 이루어졌음에도 불구하고, 불과 몇 주 후 유사한 고위험 공격이 발생하여 수백만 명이 다운로드하는 인기 NPM 라이브러리에 비트코인을 탈취하는 악성코드가 유포되었습니다.

범인은 집사였다

jQuery와 마찬가지로 Jenkins는 가장 인기 있는 오픈 소스 자동화 서버 중 하나입니다. 집사 같은 이름처럼 많은 산업 분야의 개발 팀에서 자동화 서버로 널리 사용됩니다. Jenkins가 정상적으로 작동할 때는 매우 유용한 도구입니다. 하지만 최근 발견된 결함과 엄청난 규모의 암호화폐 채굴 작업은 Jenkins가 악당들을 위해서도 많은 일을 하고 있었음을 시사합니다.

One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It's a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.

패치된 서버에서도 익스플로잇은 존재합니다. 예를 들어 Windows 환경에서 Jenkins를 실행할 때 기본적으로 NT AUTHORITY\SYSTEM 계정을 사용하여 사용자를 인증합니다. 이는 Windows 서버에서 SYSTEM 계정에 모든 권한이 부여되기 때문에 위험합니다. 개발자가 권한 계정을 변경할 수 있지만, 종종 그렇게 하지 않습니다. Jenkins가 워낙 오래된 도구라 취약점은 이미 오래전에 다 해결되었을 것이라고 안일하게 생각하기 때문입니다.

가장 최근에는 한 해커가 이러한 노후화된 Jenkins 취약점을 이용해 여러 서버를 침해했습니다. 목표는 발견 가능한 모든 취약한 Jenkins 인스턴스에 암호화폐 채굴 프로그램을 설치하는 것이었습니다. 채굴 프로그램은 암호화폐를 끊임없이 탐색하며 귀중한 컴퓨팅 자원을 낭비했습니다. 지금까지 그들은 약 350만 달러 상당의 모네로 코인 10,800개를 채굴했습니다.

옛것이 다시 새것이 되다

두 사례 모두 많은 사람이 안전하다고 믿는 플랫폼에서 기회주의적인 공격자들이 취약점을 악용하고 있습니다. 방어 측면에서는 보안 의식이 부족한 개발 관행이 해커들에게 낡은 수법을 다시 활용할 기회를 주고 있습니다. 노후화된 취약점을 이용한 공격이 다시 성공을 거두고 있음에도 불구하고, 많은 조직은 이 악순환을 끊을 계획을 세우지 않고 있습니다.

오래되었다고 해서 무해한 것은 아닙니다. 흔히 쓰이는 라이브러리나 리소스라고 해서 완전히 안전한 것도 아닙니다(예를 들어, 현재 OWASP 상위 10대 취약점 중 9위는 알려진 취약점이 있는 구성 요소 사용에 관한 것입니다). 끊임없는 노력과 지속적인 보안 교육을 통해서만 지평선 너머에서 다가오는 위험뿐만 아니라, 이미 우리 내부 깊숙이 자리 잡은 위협으로부터 스스로를 보호할 수 있습니다.