2020년 5월 19일 | Sree Sakamuri | 수석 솔루션 설계자

보안 취약점을 해결하려면 문제를 조망하는 전체적인 관점, 즉 운영 중단 사태를 최소화하는 정교한 외과적 접근 방식이 필요합니다. Oracle이 사후 패치 접근법을 취하는 반면, Spinnaker Support보다 전체적이고 예방적 세븐 포인트 보안 솔루션을 적용하고 있습니다. 

당사는 물류, 상업 또는 비즈니스의 연속성 요인으로 인해 많은 조직이 Oracle의 새로운 CPU 패치를 즉시 받아들이지 못한다는 점을 알고 있습니다. 이 관행은 해당 조직의 취약성을 노출시켜 악용당할 확률을 높이게 됩니다. 예를 들면, 다음과 같습니다. 

2020년 4월 14일일에, Oracle이 자사의 2/4분기 중요 패치 업데이트(Critical Patch Update, CPU)를 릴리스했는데, 거기에 보안 취약성 399관련 수정 사항이 포함되어 있었습니다. 겨우 2주가 지난 이후, Oracle의 안 보장 담당 이사가 고객들에게 최근 릴리스된 cpu 패치의 적용을 늦추지 말라고 권고하는 블로그 포스팅을 공개했습니다.  

CVE-2020-2883으로 식별된 특정 취약점에 대한 언급이 많은 관심을 끌었습니다. Oracle이 고객에게 패치를 신속히 적용하도록 독려하는 내용의 ‘긴급’ 블로그 포스팅을 공개할 이면에는 대개 우려의 심리가 깔려 있습니다. 

CVE-2020-2883은 원격 코드 실행(Remote Code Execution, RCE) 취약점 범주에 속합니다. 이 방법을 사용하면, 공격자는 노출된 취약점을 이용하여 원격 컴퓨터에 액세스하고 임의의 악성 코드를 실행하여 시스템을 장악함으로써 영향을 받는 전체 구성 요소/애플리케이션을 마비시킬 수 있게 됩니다. 또한 이로 인해 민감한 비즈니스 데이터가 공격자에게 노출되어 기밀성과 무결성이 심각하게 침해될 수 있습니다. 

Oracle로 하여금 블로그를 포스팅하도록 만든 계기는 무엇입니까? 

CPU가 릴리스된 다음날, 이 취약점(CVE-2020-2883)이 악용 가능함을 보이는 개념증명(proof-of-concept) 코드가 GitHub에 게시되었습니다. 얼마 후, 공격 시도에 관한 뉴스가 들끓었습니다. 우리이것이 Oracle로 하여금 해당 권고 내용을 포스팅하게 만든 원인이라고 보고 있습니다.  

Oracle의 2020년 4월 CPU 권고 게시물 외에도 신뢰할 수 있고 정확한 취약성 정보를 제공하는 믿을 만한 두 곳의 출처는 국가 취약점 데이터베이스(National Vulnerability Database, NVD)와 Mitre입니다. Mitre CVE-2020-2883에 10점 만점에 9.8점의 CVSS 기본 점수를 부여했으며, 이심각한 수준입니다. 해당 점수는 기밀성, 무결성 가용성 영향의 조합을 기반으로 매겨졌습니다.  

쉬운 말로 표현하자면, 이 CVE를 보안 및 데이터베이스/middleware 관리자의 악몽으로 만드는 요소들은 다음과 같습니다. 

  • 인증이 필요 없이 공격자가 원격으로 이 취약점을 악용 가능하다. 
  • 공격자는 특수한 액세스 조건이나 적절한 상황을 준비하지 않고서도 이 취약점을 악용하는 데 성공할 수 있다. 
  • 일단 악용되고 나면, 이로 인해 영향을 받는 구성 요소/애플리케이션의 기밀성, 무결성 및 가용성이 완전히 상실되는 결과로 이어진다. 

이 취약점의 영향을 받는 제품은 버전 10.3.6, 12.1.3, 12.2.1.3 및 12.2.1.4 Oracle WebLogic Server이며, WebLogic의 독점 RMI 프로토콜인 T3 프로토콜을 통해 노출됩니다. 이는 내부 및 외부 서비스와의 사이에 이루어지는 WebLogic의 커뮤니케이션에서 중요한 구성 요소입니다. 이 프로토콜은 WebLogic Server 에코시스템의 구성 요소 간에 트래픽을 전달하는 역할을 합니다. 

HTTP와 마찬가지로, T3는 안전하지 않습니다 

외부 소스로부터의 HTTP 트래픽을 허용하는 것은 보안 모범 사례아닙니다.  원칙은 T3에도 동일하게 적용됩니다. T3에도 T3S라는 이름의 SSL에 상응하는 요소가 있습니다. T3S는 SSL 인증서를 사용하여 HTTPS와 유사한 방식으로 트래픽을 암호화하는 T3의 보안 버전입니다.  

인터넷을 통해 들어오는 모든 T3 트래픽을 비활성화하는 것이 바람직하겠지만, 주의가 필요한 다른 문제도 있습니다. 예를 들어, 이러한 트래픽에 방화벽 수준의 차단 기능이 작동하더라도, T3 요청이 HTTPS 요청으로 포장된 채 조직의 내부 인프라로 숨어들어올 가능성은 여전히 남아 있습니다. 

안타깝게도, 이러한 문제에 대한 묘책은 없습니다. 조직은 자사의 보안 환경을 보강하기 위해 업계의 모범 관행을 따라야 하지만, 비즈니스 연속성 또한 유지해야 합니다. 

취약 지점을 울타리로 완전히 감싸고 일관된 방식으로 취약성을 줄이기 위해서는 다원화된 전략을 채택해야 합니다.: 

  1. 외부 소스로부터 HTTP/T3 트래픽이 허용되면? 방화벽 단계에서 막습니다. 
  2. Thawte, Verisign, Entrust와 같은 잘 알려진 인증 기관(CA)을 이용하여 SSL 인증서를 확보한 다음 T3S/HTTPS를 사용하여 귀사의 시스템 환경을 보호하십시오. 
  3. 방화벽 이외에도, 외부 소스의 HTTPS/T3S 트래픽만 허용하도록 사용자 맞춤형 네트워크 채널을 만들 수 있습니다. 
  4. T3 트래픽이 HTTPS 프로토콜로 숨어드는 것을 피하려면 정의된 네트워크 채널에서 터널링을 비활성화하십시오.
    1. a. 서버 -> 프로토콜 -> 채널을 선택합니다. 
    2. 채널을 선택합니다. 
    3. 터널링 활성화(Tunneling Enabled)’ 체크박스를 해제합니다. 
    4. 저장하고 변경 사항을 적용합니다. 
    5. 서버를 재시작합니다. 
  5. 방화벽 수준에서 HTTP/T3를 비활성화할 수 없는 경우, WebLogic 연결 필터 (weblogic.security.net.ConnectionFilterImpl)와 IP 화이트리스팅(방화벽)을 함께 조합하여 외부 및 내부 소스의 액세스를 제한/거부할 수 있습니다. 

위협적인 CVE 문제는 언제나 존재할 것이지만, 그에 대한 최선의 솔루션이 이미 소프트웨어에 포함된 경우가 많습니다. 경우, 저희는 귀사의 보안 환경을 더욱 강화하기 위해 알려졌지만 아주 강력한 WebLogic기능들을 활용해 보실 것을 추천합니다. 여기에는 일부 다음과 같은 기능이 포함되어 있습니다. 

  • 페리미터 인증(SAML 및 SPNEGO) 
  • 프록시, 방화벽 및 로드 밸런서의 조합 
  • 커스텀 JEP 290 역직렬화 필터 

결론 

보안 및 취약성 관리는 Spinnaker Support의 제3자 소프트웨어 지원 기본 서비스로 포함됩니다. 당사는 특정 CVE, 위협적인 문제 및 장기적인 보안 접근법과 관련하여 고객을 지원합니다. 업계를 선도하는 당사의 세븐 포인트 보안 솔루션에 대해 자세히 알아보십시오.