Team82 로고 Claroty
블로그로 돌아가기

하니웰 컨트롤엣지 가상UOC 활용하기

/

경영진 요약

Team82는 하니웰 컨트롤엣지 가상 유닛 운영 센터(UOC)를 조사한 결과, 컨트롤엣지 가상 UOC 인스턴스 내 에픽모 프로토콜 구현에서 여러 가지 취약점을 발견했습니다. 이러한 취약점은 악용될 수 있으며 인증되지 않은 원격 코드 실행으로 이어질 수 있습니다.

저희가 발견한 취약점은 하니웰 익스페리온 서버와 컨트롤러 간의 통신에 사용되는 하니웰에서 설계한 독점 프로토콜인 에픽모 프로토콜(TCP 포트 55565)에 존재합니다. 이 프로토콜에는 문서화되지 않은 위험한 기능이 포함되어 있어 가상 UOC 컨트롤러에 위생 처리 없이 파일을 작성할 수 있었고, 이로 인해 디바이스가 무단 코드 실행에 노출되었습니다. 이미 OT 네트워크에 접속한 공격자는 악성 네트워크 패킷을 사용하여 이 취약점을 악용하고 가상 컨트롤러를 손상시킬 수 있습니다. 이 공격은 파일을 수정하기 위해 원격으로 수행될 수 있으며, 그 결과 컨트롤러를 완전히 제어하고 악성 코드를 실행할 수 있게 됩니다. 

하니웰에서 가상 UOC를 업데이트했으며 사용자는 최신 버전으로 전환할 것을 권장합니다. 사이버 보안 인프라 및 보안 기관(CISA)에서 CVE-2023-5389 (CVSS v3 점수: 9.1) 및 CVE-2023-5390 (5.3)에 대한 권고를 발표했습니다. 하니웰도 권고문을 발표했습니다.

하니웰 가상 UOC란 무엇인가요?

하니웰은 산업 자동화를 위한 광범위한 컨트롤러를 제공하는 산업 제어 시스템(ICS) 시장의 중요한 기업입니다. 그 중 한 가지 제품은 Experion 제어 DCS 환경을 확장하는 모듈식 물리적 컨트롤러인 하니웰 컨트롤 엣지 UOC(장치 운영 컨트롤러)입니다. ControlEdge UOC에는 내장형 내결함성 이더넷, ModbusTCP 및 EtherNet/IP가 포함되어 있습니다. UOC는 가상 컨트롤러로도 제공됩니다. 가상 UOC는 물리적 컨트롤러가 필요하지 않으므로 기업의 하드웨어 설치 공간을 줄여줍니다. 이는 기본적으로 가상 환경에 설치할 수 있는 Linux 기반 가상 머신입니다.

하니웰 DCS 시스템의 가상UOC 위치입니다.

여러 가상 UOC 통신 프로토콜

하니웰 컨트롤러는 통신을 위해 여러 프로토콜을 사용합니다. 서비스 NameServer 는 모든 프로토콜에 대한 라우팅 및 통신 개시를 담당합니다. 특정 프로토콜을 통해 통신을 시작하려면 먼저 UDP 메시지를 NameServer 서비스(UDP 포트 12321을 통해)에 사용할 프로토콜을 지정합니다.

에픽모 프로토콜 통신을 시작하는 UDP 패킷입니다.

UDP 초기화 메시지를 전송한 후 TCP를 통해 통신을 시작할 수 있습니다. 각 세션은 프로토콜을 다시 지정하는 TCP 초기화 메시지로 시작됩니다.

에픽모 프로토콜

EpicMo 프로토콜(TCP 포트 55565)은 하니웰 컨트롤러의 디버깅 및 진단에 사용됩니다. 여기에는 다음과 같은 기능 코드가 포함됩니다. ReadMemory, WriteMemory, 재부팅 그리고 ReadCrashBlock를 사용하여 오류를 감지하고 디버깅할 수 있습니다.

프로토콜 구조

시퀀스 번호

패킷 길이

패킷 수
수신

전송된 패킷 수

기능 코드

2바이트

2바이트

2바이트

2바이트

1바이트

  • 시퀀스 번호: 패킷의 일련 번호입니다.

  • 패킷 길이: 패킷의 길이입니다.

  • 수신된 패킷 수: 수신한 패킷 수 카운터입니다.

  • 전송된 패킷 수: 전송된 패킷 수 카운터입니다.

  • 함수 코드: 클라이언트에서 호출하려는 함수 코드입니다.

파이썬으로 작성된 에픽모 프로토콜 구조체입니다.

에픽모 프로토콜을 연구하던 중 가상 UOC가 C300 컨트롤러와 다른 에픽모 기능 코드를 구현한다는 사실을 발견했습니다.

에픽모 명령 핸들러 libepa.so

우리의 관심을 끌었던 두 가지 명령은 다음과 같습니다. 모듈에서 파일 로드 그리고 모듈에 파일 로드. 이러한 기능을 연구한 결과, 가상 컨트롤러에 대한 임의의 파일 쓰기 및 파일 읽기가 가능하다는 결론에 도달했습니다.

CVE-2023-5389:

파일 쓰기에서 LoadFileToModule을 통한 사전 인증 RCE까지

(명령 0x51)

모듈에 파일 로드 를 사용하면 사용자가 컨트롤러에 파일을 쓸 수 있습니다. 이 함수가 받는 매개변수 중 하나는 목적지_경로를 입력하면 지정된 파일이 기록될 경로가 됩니다. 

이 기능을 사용하면 사용자가 임의의 경로와 데이터를 제공할 수 있으며, 주어진 경로에 대한 유효성 검사나 제한이 존재하지 않는다는 사실을 발견했습니다. 이는 사용자가 컨트롤러의 쓰기 가능한 모든 위치에 파일을 쓸 수 있다는 의미이며, 이는 보안상 문제가 될 수 있습니다. 공격자는 이 기능을 활용하여 예를 들어 실행 파일을 작성하는 등 컨트롤러에서 원격 코드 실행을 달성할 수 있습니다.

파일을 업로드하려면 모듈에 파일 로드 함수 코드를 사용하려면 최소 3개의 패킷(쓰기 시작, 데이터 쓰기, 쓰기 완료)을 전송해야 합니다. 각 패킷은 일반 에픽모 헤더로 시작합니다.

모듈에 파일 로드 쓰기 명령 시작

파일 유형

패킷 번호 업로드

알 수 없음

파일 데이터 체크섬

파일 데이터 길이

대상 경로

1 바이트

4 바이트

2 바이트

4 바이트

4 바이트

문자열

  • 파일 유형: 펌웨어 파일 또는 일반 파일. 0x05는 일반 파일에 사용됩니다.

  • 업로드 패킷 번호: 업로드 시퀀스의 패킷 번호입니다. 첫 번째 패킷은 0입니다.

  • 파일 데이터 체크섬: 전체 파일 데이터의 체크섬

  • 파일 데이터 길이: 전체 데이터의 길이

  • 대상 경로: 대상 경로: 컨트롤러에 저장할 파일의 이름입니다.

모듈에 파일 로드 데이터 명령 

데이터 명령에 포함된 파일 데이터의 최대 길이는 0x7F입니다. 데이터 길이가 0x7F를 초과하는 경우 여러 패킷으로 분할되어 업로드 패킷 번호가 그에 따라 업데이트됩니다.

파일 유형

패킷 번호 업로드

데이터 길이(최대 0x7f)

데이터

1 바이트

4 바이트

2 바이트

n-바이트

모듈에 파일 로드 최종 명령 

최종 명령은 업로드가 완료되었음을 알리는 데 사용됩니다.

파일 유형

패킷 번호 업로드

데이터 길이: 0이어야 함

1 바이트

4 바이트

2 바이트

업로드 패킷 번호가 0이 아니고 데이터 길이가 0이면 최종 업로드 패킷으로 간주합니다.

유효한 모듈에 파일 로드 시작 명령을 사용하려면 파일의 체크섬을 포함해야 합니다. 파일의 체크섬을 계산하기 위해 주어진 파일에 대해 올바른 체크섬을 반환하는 다음 함수를 구현했습니다(아래 참조).

공격자가 이 취약점을 이용해 원격 코드 실행을 달성하는 방법을 보여주기 위해 가상 컨트롤러에서 쓰기 가능한 위치를 검색했습니다. 하지만 몇 가지 한계가 있었습니다:

  1. 다음을 사용하여 업로드한 파일 모듈에 파일 로드 UNIX 실행 속성이 없습니다.

  2. 다음에 마운트되는 모든 파일 /usr/honeywell 는 읽기 전용으로 마운트되며 이 디렉터리는 쓸 수 없습니다.

결국 시스템 .so 파일을 덮어쓰기로 결정했습니다. .so 파일에는 실행 속성이 필요하지 않으며, 코드가 로드될 때 코드를 실행할 공유 객체를 만들 수 있습니다. 우리는 /lib/libcap.so.2 를 공유 오브젝트로 덮어쓰지만, 시작 시 로드되므로 덮어쓰더라도 런타임에 큰 영향을 미치지 않으며 안정적인 사전 인증 RCE가 가능합니다. 

코드 실행 흐름은 다음과 같습니다:

  1. 컴파일 libcap.so.2 시작 시 페이로드가 실행되도록 설정한 상태에서

  2. 사용 모듈에서 파일 로드 에 파일을 쓰려면 /lib/libpcap.so.2 컨트롤러에서

  3. 재부팅 명령을 호출하여 다음을 다시 로드합니다. libcap.so.2

마지막으로 CVE-2023-5389를 사용하여 원격 가상 UOC에서 사전 인증 RCE를 시연할 수 있었습니다.

결론 

하니웰 익스페리온 서버와 컨트롤러 간의 통신에 사용되는 하니웰의 에픽모와 같은 독점 프로토콜은 종종 산업 프로세스를 조작하거나 중단시킬 수 있는 취약점을 포함하고 있습니다. 

저희는 살균 처리 없이 가상 UOC 컨트롤러에 파일을 작성하여 원격 코드 실행을 가능하게 하는 기능을 가진 메커니즘을 발견했습니다.

문서화되지 않은 위험한 기능이 발견되어 가상 UOC 컨트롤러에 위생 처리 없이 파일을 쓸 수 있게 되었습니다. OT 네트워크의 공격자는 컨트롤러에 악성 패킷을 전송하고 컨트롤러에 대한 인증 없이 파일을 쓸 수 있었습니다. 

Team82는 이러한 취약점인 CVE-2023-5389 및 CVE-2023-5390을 하니웰에 비공개로 공개했으며, 하니웰은 업데이트를 통해 해당 취약점을 해결했습니다.

최신 소식 받기

Team82 뉴스레터 받기

관련 취약점 공개

Claroty
LinkedIn Twitter YouTube Facebook