Secure Internet Access Enterprise 보안 웹 게이트웨이로 악성 자바스크립트 탐지

개요 

자바스크립트가 없는 세상을 상상해 보세요. 동료들과 저는 커리어의 어느 지점에서는 결국 이런 일이 일어나지 않을까 수없이 상상해봤지만, 현재로서는 자바스크립트가 없는 세상은 상상하기 어렵습니다. 지난 몇 년 동안 자바스크립트를 사용해 온 회사에서 일하고 있는 사람으로서 저는 자바스크립트 관련 문제와 업계에서 이것이 얼마나 널리 사용되고 있는지 잘 알고 있습니다. 사실, 자바스크립트 보안은 우리가 좋아하든 싫어하든 간에 우리의 미션에서 큰 부분을 차지합니다. 

자바스크립트는 어디에나 있습니다. 웹 사이트 및 모바일 애플리케이션에 대한 모든 요청은 수십 줄의 자바스크립트 코드를 로딩하며, 모든 브라우저에서 이를 지원합니다. 어디에나 있기 때문에 웹 사이트의 구축 및 작동 방식을 결정해 주는 중요한 기술로 쉽게 간주될 수 있습니다. 그리고 우리가 모두 알고 있는 것처럼, 보안에서는 더 중요한 기술일수록 악의적으로 사용될 수 있는 방법이 많습니다.

널리 보급되어 있기 때문에 자바스크립트를 사용하면 공격자들이 그 거대한 공격표면을 악용하여 상당한 피해를 줄 수 있습니다. 대규모 기법으로 인한 잠재적인 영향은 2021년 12월에 발견된 Log4j 취약점으로 설명되며, 이 공격 기법은 악용되는 즉시 확장됩니다. Log4j는 Java 라이브러리로서 거의 모든 개발자가 사용하는 기본 기능인 로깅 기능을 제공합니다. 자바스크립트 취약점은 다른 취약점과 다르게 프로덕션 코드 사이에서 두드러집니다. 

이런 상황에서, 언제나 존재했던 질문을 하게 됩니다. “이 취약점을 어떻게 해결할 수 있을까?” Log4j가 초래한 혼란을 확인한 후, 우리는 질문에 대한 확실한 답을 찾기로 하고 악성 자바스크립트를 이해하고 탐지하기 위한 조사를 시작했습니다. 그리고 제가 현재 글을 작성 중인 이 프로젝트로 연결되었습니다. 보안 연구는 항상 재미있었고, 우리의 이론이 작동한다는 것을 확인했을 때 한 걸음 더 나아가 몇 가지 실제 상황을 시도해 보기로 했습니다. 

이 블로그 게시물에서는 제품에 새로운 기능을 구축하기 위해 악성 자바스크립트를 탐지하고 분리하는 데 사용한 기술과 조사에 대해 알려드릴 것입니다. 여기에는 시스템 아키텍처, 적용된 알고리즘 및 사례 연구를 비롯하여, 자바스크립트 관련 위협 환경에 대한 검토가 포함됩니다. 

악성 자바스크립트 위협 환경

프로젝트를 자세히 살펴보기 전에 악성 자바스크립트가 눈에 띄는 위협 기법이 되는 환경에 대해 알아보겠습니다. 제가 이미 자바스크립트가 많이 쓰인다고 설명했지만, 실제로 어느 정도일까요? 이를 이해하면 프로젝트를 보는 관점을 갖게 됩니다. 자바스크립트를 사용하는 가장 널리 알려진 공격 중 일부는 아래와 같습니다.

브라우저 악용 

브라우저와 브라우저 플러그인은 컴퓨터를 사용하는 모든 사람에게 핵심 요소이므로, 이와 관련한 위협이 얼마나 큰지 강조할 필요가 없습니다. Browser Exploitation Framework Project(BeEF)가 좋은 예시입니다. BeEF는 가장 큰 클라이언트 측 공격 벡터 중 하나인 웹 브라우저에 초점을 맞춘 모의 해킹 툴로, 그 악용 가능성을 잘 보여줍니다. 

스키머 

스키머는 사이버 보안이 기업 바깥의 삶에 어떤 영향을 미치는지, 그리고 어떻게 매우 개인적인 문제가 될 수 있는지 보여주는 악명 높은 예시입니다. 자바스크립트는 문서 객체 모델을 제어하기 때문에 생성된 HTML은 물론, 중요한 HTTP 요청도 수정할 수 있습니다. 이는 사용자가 버튼을 클릭하는 것과 같은 간단한 동작에서 확인할 수 있습니다. 

이에 대한 실제 사례는 디지털 상거래와 관련된 모든 사이트에서 파생될 수 있습니다. 악성 자바스크립트가 정상 웹 사이트에 주입되면 스키머가 캡처한 모든 신용 카드 인증정보가 공격자에게 리디렉션될 수 있습니다. 가장 주목할 만한 사례는 2018년 British Airways 웹 사이트에 대한 Magecart 공격으로 약 380,000개의 신용 카드 번호가 도용되었습니다. 

스키밍은 2018년 이후로 변형되었습니다. 오늘날 이 기술이 사용되는 일반적인 방법은 정상 웹 사이트에서 비트코인 주소를 공격자의 주소로 바꾸는 것으로, Lazarus Group에서 이 방법을 지난 몇 년간 사용했습니다. 

클릭재킹 

정상 웹 사이트에서 운영하면 광범위한 배포가 가능하지만, 모든 권한을 유지하는 서버에 비해 범위가 제한적입니다. 공격자가 사용자를 유인할 수 있다면 홈 코트 이점을 갖게 되는 셈이고, 이것은 공격자에게 훨씬 더 큰 영향력을 가져다줍니다. 피해자가 자신의 구역에 도착하면, 공격자는 피해자가 멀웨어를 다운로드하고 브라우징 세션에서 정보를 검색하며 다른 많은 악의적인 활동을 수행하도록 할 수 있습니다.

이를 위한 전형적인 한 가지 방법으로 정상적인 iframe 위에 투명한 iframe을 만들어 사용자가 클릭할 때 보안 상태에 대해 잘못된 진단을 하도록 합니다. 이 iframe은 공격자가 수많은 악의적인 활동을 실행할 수 있는 공격자 제어 서버로 사용자를 리디렉션합니다.

무단 크립토마이닝 

크립토마이닝은 오늘날 사용되는 암호화폐가 많이 증가하면서 지난 몇 년 동안 많은 주목을 받고 있습니다. 사용자의 CPU를 사용하여 암호화폐를 채굴하지 않는 이유가 있으며, 특히 자바스크립트 한 줄만 사용하는 경우에는 더욱 그렇습니다. 이와 관련된 가장 유명한 라이브러리는 Coinhive로 2019년에 폐쇄된 것으로 알려졌지만 이후 비슷한 사례인 CoinIMP 또는 CryptoLOOT로 대체되었습니다.

악성 자바스크립트 탐지 엔진 - 아키텍처 및 알고리즘 

이제 전체적인 환경을 파악했으니, 우리가 만든 것을 살펴볼 차례입니다. 자바스크립트를 웹 사이트에 삽입하는 방법에는 두 가지가 있습니다. 하나는 동일한 서버에 자바스크립트 파일을 작성하는 방법이고, 다른 하나는 다른 소스의 기존 파일을 사용하여 HTML 페이지에 링크를 삽입하는 방법입니다. 프록시 측에서는 HTML과 자바스크립트 파일용으로 각각 하나씩, 두 개의 서로 다른 HTTP 요청을 볼 수 있습니다. 단일 웹 사이트를 입력하면 브라우저가 전체 웹 사이트를 렌더링하기 위해 수백 개의 HTTP 요청을 수행할 수 있습니다.

HTML 자체 내에서 자바스크립트 코드를 작성할 수도 있습니다. 이렇게 하면 가져오기 위한 추가 요청이 필요하지 않습니다. 따라서 악성 자바스크립트를 탐지할 때 이 두 가지 유형을 모두 해결할 방법이 필요하며, 우리가 이것을 만들었습니다.

우리의 새로운 엔진은 ‘인라인’ 자바스크립트 코드를 추출하고 별도로 스캔할 수 있습니다. 다음은 이 두 가지 유형의 자바스크립트를 보여주는 The New York Times 소스 페이지에서 추출한 것입니다.