임베디드 TCP/IP 스택의 심각한 결함, 산업용 제어 장치가 위험하다

임베디드 장치, 특히 산업 자동화용에 사용되는 장치는 소프트웨어에 대한 취약점에 대한 인식이 지금처럼 자리잡지 않았던 시절에 개발된 내부 자체 코드와 서드파티 코드를 혼합해 사용하는 경우가 많다. 따라서 하드웨어 공급업체가 널리 사용해 온 여러 요소들에서 치명적인 결함이 발견되면 그 영향은 매우 크다. 게다가 패치를 적용할 수 없는 경우도 존재한다.

 

여러 시장조사업체가 내놓은 조사결과를 보더라도 이 같은 문제점이 고스란히 드러난다. 최근 "INFRA:HALT"라는 제목으로 발표된 보고서에 따르면 200여 개의 공급업체의 운영 기술 장치에 널리 사용되고 있는 니치스택(NicheStack)이라는 사유 TCP/IP 스택에서 14개의 치명적인 취약점이 발견 되었다. 이로 인한 악영향을 받는 장치에는 지멘스 S7과 같은 PLC도 포함되어 있다.

 

TCP/IP 스택이나 각종 프로토콜 모음은 일반적인 인터넷 프로토콜 구현으로 구성되며, IP 네트워크를 통해 데이터를 송수신할 수 있게 해준다. 이 처럼 이 스택이 지원하고 처리하는 형식이 많기 때문에 무단으로 악용될 수 있는 공격범위도 상당히 크다고 볼 수 있다.

 

산업 제어 장치도 최근 이더넷 인터페이스를 도입하는 경우가 늘고 있고 이더넷에는 TCP/IP 스택이 자연스럽게 따라오기 때문에 이 역시 공격에 취약해질 가능성이 높다.

 

게다가 산업용 제어 장치는 사유 실시간 운영체제(Real-Time Operating Systems, RTOS)를 사용하는 경우가 많다. 이런 RTOS는 버전 관리가 제대로 되지 않고 각자의 상황에 맞게 쉽게 수정되고 소유권이 변경되기도 한 사유 TCP/IP 스택을 사용하기 때문에 취약한 제품을 찾아서 패치하기도 매우 어렵다.

 

니치스택은 인터니치 테크놀로지라는 기업이 개발한 TCP/IP 스택으로 지난 20여년 동안 여러 RTOS에서 사용하기 위해 여러 가지 변형으로 배포되었다.

 

발견된 14개 취약점 가운데 대부분은 버퍼 오버플로우와 대역 외 메모리 읽기/쓰기 인데 이와 같은 취약점은 여러 인터넷 프로토콜 등을 통해서 악용될 소지가 있으며 원격 코드 실행이나 서비스 거부 조건으로도 이어질 수 있다. 이 외에도 기타 다른 결함의 원인등은 TCP 스푸핑이나 DNS 캐시 포이즈닝과 같은 공격도 가능하게 할 수 있다. 

 

두 개의 원격 코드 실행 결함은 위험 등급이 매우 치명적인 등급에 해당하고 서비스 거부 문제의 심각도 지수도 7.5 또는 8.2에 이를 만큼 심각한 수준이다. 특히 산업용 제어 시스템에 있어서는 악영향을 받는 장치가 제어하는 산업 공정이 어떤 것이냐에 따라 매우 심각한 영향을 끼칠 수도 있다.

 

조사기관은 취약점 조사 결과를 공개하기 전에 관련된 여러 기관에 대응과 관련한 협력을 수행했다. 하지만 이렇게 해도 영향을 받을 가능성이 있는 장치와 공급업체를 찾는 것이 매우 어려웠고 지금도 찾는 중이다. 이들 협력기관과 업체들은 자체 프로그램과 데이터베이스등을 사용해서 21개 공급업체에서 2,500개의 잠재적으로 취약한 장치를 발견했는데, 이 가운데 가장 큰 영향을 받는 분야는 공정 제조, 소매 등의 분야로 파악된 장치의 약 절반이 에너지 및 전력 산업 제어 시스템이었다.

 

하지만 발견되고 조사된 공급업체의 수는 적지만 실제 영향을 받는 장치의 수는 수백 만개에 이를 것으로 추정된다.

 

HCC 임베디드는 이러한 문제에 대응하기 위해 취약점에 대한 패치를 개발했지만 이 패치는 고객이 요청하는 경우에만 제공되며 고객의 대부분은 장치 제조업체다. 영향을 받는 제품의 최종 사용자는 각각의 장치 제조업체가 패치를 적용할 때까지 기다려야 한다.

게다가 오래 전에 이 TCP/IP 스택을 제품에 통합한 모든 공급업체가 HCC 임베디드와 여전히 연락을 유지하고 있을 가능성은 높지 않고, 특히 중소 공급업체라면 더욱 기대하기 어렵다. 또한 영향을 받는 일부 장치는 지원 종료 시점을 넘겨 패치를 받지 못할 수도 있다. 한 마디로 대다수의 업체가 이 패치를 공급받을 수 없다는 것이다.

코스탄트는 “또 다른 문제는 자산 소유자에 있다. 패치가 제공되더라도 소유자가 영향을 받는 장치를 갖고 있는지 알고 있느냐가 문제”라면서 “모든 장치를 완전히 인벤토리화하지 않은 경우도 있으므로 위험을 평가하는 것조차 쉽지 않다”라고 지적했다.

포스카우트는 문제를 해결하기 위해 오픈소스 스크립트를 개발하기도 했다. 자산 소유자는 이 스크립트를 사용해 네트워크에서 니치스택, 또는 이전에 프로젝트 메모리아(Project Memoria)라는 이름으로 수행된 더 큰 규모의 조사에서 발견된 취약점이 있는 다른 TCP/IP 스택을 실행하는 장치를 찾을 수 있다. 또한 포스카우트는 영향을 받는 장치를 찾고 악용 시도를 탐지할 수 있도록 자체 상용 제품을 업데이트했다.

패치 배포의 또 다른 문제는 영향을 받는 장치 중에는 공장 또는 산업 시설에서 필수적이거나 상시 가동해야 하는 공정을 제어하거나 원격지의 현장에 구축되어 있다는 것이다. 이 경우 예정된 유지보수 없이 즉시 가동 중단과 업데이트가 불가능하다. 코스탄트는 “대다수 공급업체, 특히 규모가 작은 경우 패치보다는 영향 완화가 더 효과적일 것”이라고 말했다.

취약점을 완화하기 위해 포스카우트는 다음과 같이 조언을 한다.
  

• 세그먼트화 제어와 적절한 네트워크 위생을 통해 취약한 장치에서 발생하는 위험을 완화한다. 취약한 장치를 패치할 수 없는 경우(또는 패치가 가능해질 때까지) 위험 완화 수단으로 외부 통신 경로를 제한하고 취약한 장치를 따로 격리해야 한다.  
• 영향을 받는 공급업체가 배포하는 패치를 모니터링하고 취약한 자산 인벤토리에 대한 교정 계획을 마련해 비즈니스 위험과 비즈니스 연속성 요구사항 간의 균형을 맞춘다.
• 모든 네트워크 트래픽에서 알려진 취약점을 이용하려 시도하는 악성 패킷 또는 제로데이를 모니터링한다. 이상 트래픽이나 기형적인 트래픽은 차단하거나 최소한 네트워크 운영자에게 해당 트래픽의 존재를 알려야 한다.
• DNSv4 클라이언트가 불필요하다면 비활성화하거나 DNSv4 트래픽을 차단한다. 여러 취약점이 DNS 스푸핑 공격을 가능하게 하는 원인이 되므로 내부 DNS 서버를 사용하는 것으로는 충분하지 않을 수 있다(공격자가 요청-응답 매칭을 가로챌 수 있음).
• HTTP가 불필요하다면 비활성화하거나 HTTP 연결을 화이트리스트로 작성한다.
• 트래픽에서 기형적인 IPv4/TCP 및 ICPMv4 패킷을 모니터링해 차단한다. 

 

참고 : <ITWORLD - Lucian Constantin CSO>