베라포트(VeraPort)는 인터넷 뱅킹과 같은 사이트에서 사용하는 여러 보안 프로그램의 한 종류로, 인터넷 뱅킹에 사용하는 여러 보안 프로그램을 통합하여 설치하고 관리하는 솔루션입니다.
2020년 11월 16일 보안전문회사 'ESET' 는 베라포트를 관리하는 서버가 공급망 공격(Supply Chain Attack)을 받았다고 발표하였습니다. [1]
공급망 공격이 무엇이고, 어떻게 공격을 받았는지, 그리고 어떤 파급 효과가 발생했는지 하나씩 살펴보겠습니다.
공급망 공격(Supply Chain Attack)
공급망 공격에 대해 이해하려면 먼저 우리가 사용하는 IT 제품과 서비스가 어떻게 제공되는지를 이해해야 합니다.
IT 제품/서비스가 소비자에게 공급되는 과정
위 그림은 일반적인 상품이 우리에게 오기까지의 과정을 나타낸 것입니다. IT 제품/서비스도 크게 다르지 않습니다.
공급자
일반적인 상품에서 공급자는 제품생산에 필요한 재료들을 제공하는 역할을 합니다. IT 제품/서비스에서 공급자의 위치에 있는것은 라이브러리라 할 수 있습니다. 개발자들은 목적에 맞는 기능을 제공하는 여러 라이브러리들을 사용하여 IT 제품/서비스를 개발을 합니다.
제조 업체
IT 제품/서비스를 제작하는 업체입니다. 공급자에서 언급한것처럼 개발자는 여러 라이브러리를 사용하여 제공하고자 하는 제품/서비스를 제작하게 됩니다.
배송 업체
IT 제품/서비스를 제작하였다면 이를 소비자에게 전달해야 합니다. 때에 따라 소프트웨어의 형태로 제공할 수 있고 웹 형태로 제공을 할 수도 있습니다. 만약 소프트웨어의 형태로 제공을 한다면 소프트웨어를 다운받을 수 있는 사이트가 필요한데, 대부분의 회사가 CDN서비스를 이용하여 제공합니다. 웹 형태로 제공하는 형태 역시 서비스에 대한 처리는 제조 업체에서 담당하지만 이미지, .js파일, .css 파일 등 정적인 파일들 역시 CDN을 통해 제공하는것이 일반적입니다.
계속 언급되는 CDN이란 content delivery network의 약자로, 인터넷으로 빠르게 컨텐츠를 공급할 수 있도록 돕는 서비스입니다. 제조 업체가 소비자에게 전달하고 싶은 콘텐츠를 CDN에 올려놓으면, 소비자들은 제조 업체가 아닌 CDN에 접속해서 콘텐츠를 내려 받을 수 있습니다.
공급망 공격(Supply Chain Attack) 이란?
공급망 공격이란 위에서 설명한 공급망을 구성하는 각 요소(공급자, 제조 업체, 배송 업체) 들을 공격하는 것입니다. 각 요소에 대해 가능할 수 있는 공격은 다음과 같습니다.
공급자
공급자에 대해서는 라이브러리를 통한 공격이 가능합니다. 2가지 경우가 있을 수 있습니다.
하나는 제조 업체가 사용할만한 라이브러리를 만들고, 백도어를 심는 것입니다. 이에 대한 예로는 nodejs의 패키지 저장소인 NPM에 올라온 getcookies
[2] 가 있습니다. 해당 패키지는 특수한 헤더가 포함된 HTTP 요청을 처리할때 백도어가 실행되는 악성 패키지입니다. 이는 해커가 악성 라이브러리를 공급하여 공급망 공격을 시도한 것으로 해석됩니다.
다른 하나는 제조 업체가 사용하고 있는 라이브러리의 업로드 권한을 해킹하여 백도어가 심어져 있는 버전을 새로 올려두는 것입니다. 라이브러리를 만드는 개발자들은 NPM, PyPi과 같은 패키지 관리 사이트에서 발급해준 토큰을 사용하여 라이브러리를 업로드 합니다. 만약 이 토큰이 해킹당하여 탈취당할 경우 백도어가 심어져 있는 새로운 버전의 라이브러리를 올릴 수 있습니다. 이에 대한 예로는 python의 패키지 저장소인 PyPi에 올라가 있던 ssh-decorate
패키지입니다.[3] 해당 패키지는 이스라엘 개발자 Uri Goren이 만든 패키지인데 어떤 해커가 Uri Goren의 토큰을 탈취하여 ssh관련 백도어를 소스코드에 삽입한뒤, 이를 재배포하였습니다. 만약 이렇게 백도어가 심어져 있는 라이브러리를 제조 업체가 그대로 사용할 경우 해당 백도어는 소비자에게까지 전달될 것입니다.
제조 업체
제조 업체를 대상으로도 공급망 공격이 발생할 수 있습니다. 제조 업체의 내부 시스템에 따라 공격 방식이 다양하지만, 보편적으로 발생하는 2가지 공격 형태가 있습니다.
하나는 해커는 제조 업체의 소스코드 관리 서버나 빌드 서버를 해킹한 경우입니다. 이 경우 해커가 개발자 몰래 백도어를 소스코드나 최종 빌드 결과물에 삽입할 수 있습니다.
또다른 경우는 인증서가 탈취당하는 경우입니다. 대부분의 소프트웨어 제조 업체는 자신들이 만든 소프트웨어를 인증서로 서명하여 이 소프트웨어는 자신들이 만들었고 제 3자에 의해 수정되지 않았음을 보증합니다. 그런데 인증서를 통한 소프트웨어 보증은 인증서가 탈취당했을 때 오히려 심각한 보안 문제를 야기할 수 있습니다. 예를 들어, 해커가 자신이 만든 악성 코드에 제조 업체의 인증서로 서명하면, 백신 프로그램은 해당 제조 업체를 신뢰하여 악성 코드를 제대로 검사하지 않습니다.
배송 업체
마찬가지로 배송 업체를 대상으로도 공급망 공격이 발생할 수 있습니다. 제조 업체가 제대로 안전하게 제품을 만들어 냈더라도 제품을 배송해주는 배송 업체가 해킹당하면 결국 소비자에게는 백도어가 심어져 있는 제품이 전달될 수 있습니다. 특히 소프트웨어 제조사는 배송 업체(CDN)의 보안에는 전혀 관여할 수 없기 때문에 배송 업체가 해킹당해도 이를 인지하기가 매우 어렵습니다.
배송 업체를 대상으로 자주 발생하는 공격으로는 업데이트 서버에 대한 공격이나 웹사이트에서 사용되는 자바스크립트 코드의 수정 등이 있습니다.
베라포트의 경우는?
앞서 설명한 것처럼 베라포트는 인터넷 뱅킹에 사용하는 여러 보안 프로그램을 통합하여 설치하고 관리하는 솔루션입니다. 즉 다른 보안 서비스들의 배송 업체로 분류를 할 수 있습니다.
베라포트는 실행시 미리 구성된 XML파일을 인터넷으로부터 받아와 해석합니다. 해당 XML에는 보안 프로그램을 설치하기 위한 다운로드 URL이 적혀있고, XML자체는 인증서를 통해 서명되어 있습니다.
(출처: https://www.welivesecurity.com/2020/11/16/lazarus-supply-chain-attack-south-korea/)
따라서 베라포트가 설치되어있는 클라이언트는 XML파일에 대한 검증이 가능해 안전하게 보안 프로그램 설치파일들을 다운로드 하는것이 가능합니다.
하지만 XML파일을 통해 받은 보안프로그램 자체에 대한 검증은 부족했습니다. 베라포트는 보안 프로그램을 다운받은 뒤 해당 프로그램의 서명에 대한 검사를 진행합니다. 이때 서명이 되어있는지만 검사하고 서명을 누가 했는지에 대해 검사를 하지 않았습니다. 사실 베라포트는 서명을 누가 했는지에 대한 검사를 진행하는 옵션도 존재했지만, 공격당한 사이트의 경우 해당 옵션에 대한 구성이 없었습니다. 공격자는 이 점을 이용해 ALEXIS SECURITY GROUP, LLC 의 인증서와 DREAM SECURITY USA INC의 인증서를 탈취하고, 해당 인증서로 악성코드가 심어진 프로그램을 서명하여 베라포트의 서버에 업로드 하였습니다.
(출처: https://www.welivesecurity.com/2020/11/16/lazarus-supply-chain-attack-south-korea/)
(출처: https://www.welivesecurity.com/2020/11/16/lazarus-supply-chain-attack-south-korea/)
결국 소비자는 악성코드가 심어진 프로그램을 받아 감염되게 됩니다.
결론
현재는 조사가 끝나고 더이상 악성코드가 배포되지 않는것이 확인되었습니다. 하지만 이런 공급망 공격은 해커의 입장에서 적은 노력으로 많은 파급력을 노릴 수 있는 매력적인 공격 시나리오기 때문에 앞으로도 계속 공급망 공격이 발생할 수 있습니다.
소비자의 입장으로써는 믿을 수 있는 경로로부터 IT 제품/서비스를 받은것 뿐이기에 자신이 공격을 당했다는 사실을 알기 힘듭니다. 따라서 IT 제품/서비스를 제공하는 업체는 공급망 공격에 자신이 당했는지 항상 경계해야 할 필요가 있습니다